Is it worth to learn COM?

Question

I am thinking to learn COM.But I heard that Microsoft launched .NET as an alternative to COM. So is it worth to learn COM? actually I started learning COM for UMDF device driver. Is there any alternate way to work on UMDF except COM?

Answer 1

COM is old, tedious and frustrating. I don't think anyone has ever enjoyed working with COM. So generally, I'd recommend against learning it unless you have a really compelling reason. If there is a COM library out there that you need to use, I'd instead learn how to use it through COM interop, which enables you to work with COM from .NET.

Answer 2

COM was useful because it allowed you to build a language independent API that could be consumed from multiple languages. Now .net is used for roughly the sampe purpose, although it is less accessible. If you program .net, many COM API's "just work", although it is good to get some basic understanding of how COM works (such that COM uses refcounting for memory management, whereas .net uses garbage collection).

Answer 3

UMDF is a framework to develop user mode device drivers. I think a key requirement for a device driver is: load fast. I don't want to delay my startup times just because I have a funky device driver that has to load and JIT the .NET framework (preJITed but nonetheless).

Sure you can develop bloated com libraries too but by being competent you can avoid it. You can't avoid .NET runtime.

So even if UMDF allowed for .NET development I at this point of time wouldn't want device drivers written in .NET.

Don't get me wrong. I love .NET. I just don't think it mixes that well with device drivers even if we are talking about usermode drivers.

When looking at COM I think it helps to understand why it was developed: to provide interopability between components developed in different environments. This was back in the '80s. Now people has complained about COM over the years but it is actually very successful at that. There were some mistakes in the deployment model of COM (ie the registry dependency) and other interesting design choices that have made developers scratch their heads. However, the core of COM (ie IUnknown) is still sound IMO.

Answer 4

To be clear, .NET was very much intended to be a replacement for COM. And that worked out well, it's been very successful. But COM is everywhere in Windows, you can't shake a stick at a typical program and not run into COM somewhere. That starts with the very first bit of code in any .NET GUI program, [STAThread].

There is lots and lots of stuff in Windows that hasn't gotten the friendly .NET wrapper yet. That isn't always needed, the CLR has excellent support for COM interop. Quite visible from the Add Reference dialog, the COM tab is filled with goodies. But what you see in that list are components that were specifically engineered to be easy to use from any runtime environment. They implement a subset of COM called "OLE Automation".

Automation is a very restricted subset, it works so well because what you actually can do is limited. There are however gobs of code that don't fit that subset. The kind for which you can't find a type library. Without the type library you're screwed in .NET. The most visible component with that issue is the shell. Windows Explorer. Writing a shell extension in managed code is hard.

The issue is that COM interface declarations were originally designed to work well on a compiler that implements multiple inheritance. C++ specifically. A .NET interface declaration does not map well to a COM interface if that COM interface was derived from another COM interface. The CLR generates the wrong v-table. This is touched upon in this MSDN magazine article, albeit that the author's conclusion is quite wrong.

You can write COM interface declarations in a .NET language and implement them. It is just that you get no help at all from the SDK. And that you'll need to know COM pretty well to get them right.

UMDF fits this model too, its interfaces are derived from IUnknown. No type library. No managed wrapper that I know of. You could write your code in C# but you'll have to write all the interface declarations yourself. Realistically, only C++ applies here.

Yes, you'll need to learn COM.