Com Is Not

ComIsNot: COM (ComponentObjectModel) is an extremely flexible substrate for building distributed object systems or components. These components can be built in any language that supports the COM standard for layout of binary objects and callable from any language that either has this layout or supports the late binding interface IDispatch.

COM is:

COM clients *never* get a pointer to a COM object. They always get a pointer to an interface of that object.

COM does give you a defined interface: IUnknown, from which all other interfaces must be derived. IUnknown provides for reference counting (via AddRef/Release) and runtime interface discovery/navigation -- dynamic type casting (via QueryInterface).

OLE defines several interfaces to do with object linking and embedding. These interfaces are on top of COM. DirectX defines interfaces for gaming. DirectShow defines interfaces for media streaming. etc., etc. These are also on top of COM.

MTS was a separate add-on product (NT Option Pack) which leverages this further to provide for other stuff like just-in-time activation (JITA), object pooling (lowers instantiation costs by reusing objects), transactions, etc.

ComPlus gets its name from COM + MTS + MSMQ + OTHER NEW FEATURES (like the new publish/subscribe event system). ComPlus merges the COM and MTS object models into one object model and puts the runtime into the kernel. It adds a list of features detailed on the ComPlus page. It doesn't necessary do anything different with DCOM (DistributedCom)... DCOM is really just COM over the wire, where location transparency means something more than just being outside an apartment or local process, adding the possibly of communicating with an instance of a component running on entirely different machine.


I'd prefer that this page not degenerate into a ThreadMode discussion. Ways that I think will avoid this are the following:



As one who has worked with COM since its beta in 1993 and taught it, I went and re-factored the above. -- SamGentile


So, what's the story with Microsoft abandoning shared COM objects as code reuse? That is, storing multiple versions of the same COM object on the system, and then having each application maintain a manifest of the objects and versions they require? Actually, it's naturally because ComponentOrientedProgramming as code reuse doesn't work at the interface level because the interface isn't implementation. But how does this affect COM's usefulness? Why not just use DLLs (for INPROC COM objects)? I'm not trolling here either; I just don't get it anymore. I love COM, but it seems so useless now. -- SunirShah

I assume you are referring to DotNet's model and COM being dead. First of all, COM is not dead and COM+ continues to evolve and get new features. DotNet has each Assembly (not application) maintain a manifest of the objects and versions they require. Why is this a win? Because this gets rid of the COM problem of having to register things in the Registry. This also allows a DotNet app to use xcopy deployment: you just simply copy all the assemblies and files to some directory and party on. No more registration. No more registry. Your other question I don't understand: COM DOES use DLLs for INPROC COM objects. Let me know if this is not clear. Thanks for your interest. -- SamGentile

Apparently, in the latest versions of Windows (don't know exactly; I'm a Palm developer now), applications will no longer be able to use registered COM objects, but have to use that manifest thing. I recognize the reason being version inconsistencies. This is because component-oriented programming does not create code reuse (nothing does). So, it would seem that it's cheaper for applications to just statically link everything, except for the problem bugfixes and patches.

I don't believe that is true. I am using the latest Whistler and I can still register and use old-style COM objects.

In those cases, splitting the application into modules makes it easier to contain changes to small binaries. However, that doesn't explain what all the complication of COM is good for. A plain vanilla DLL seems like a better choice than a COM object. You lose the thread model, but that's really not much of an issue anyway.

Why? DLLs can't be versioned. COM Interfaces can be. In Proc COM Objects are DLLs.

Out of process COM objects have advantages, especially if they are persistently loaded and shared. But in process COM objects are just complication and overhead that isn't really necessary.

How so?

By the way, a nicer modularization scheme might be like Java's .class system, except that (just like everything in Java ;) it's broken. Perl has a good model too. Reports of C# indicate it's actually doing the right thing, which is super nice. But that doesn't leave much room for COM for normal applications.

Then again, maybe the IDispatch interface is enough reason? Interlanguage operability? I'm not entirely sure about that. DLLs work for that too, in most cases. Maybe a better question is "What does an INPROC COM object do for you now?" -- SunirShah

IDispatch is for dumb VB and scripting languages. DLLs and COM are not really a valid comparison unless you are comparing them for code reuse and then InPROC COM solves is that the lack of a C++ binary standard limits what language features can be used across DLL boundaries. Simply exporting C++ member functions is not enough to create a vendor-independent component substrate. Also, because C++ requires the client knowledge of object layout, C++ introduces a tight binary coupling between the client and object executables. So versioning is impossible. COM solves these issues and more. It allows a client to select and load binary components dynamically that can evolve their implementation layout over time without requiring client recompilation. Also an INPROC COM component provides RTTI of interfaces across multiple vendor's compilers and languages. The last area is resource management. A INPROC COM object can go away when there are no outstanding references.

-- SamGentile

EditText of this page (last edited September 20, 2005) or FindPage with title or text search