COM: Microsoft Component Object Model

• COM is a way of defining interfaces that can be used from C++, C, and other languages.
• COM specifies how objects interact within a single application or between applications. -OLE 2 Programmer's Reference.
• COM has a specific set of services that it provides:
  • Interface Negotiation
  • Memory Management
  • Error and Status Reporting
  • Interprocess Communication
• COM is a binary object standard, because it defines the layout of objects in memory, as an interface table, a table of pointers to functions, like C++ vtables. It is language independant, in that it can be used by any language that can support its binary object layout and calling conventions.
• Part of Win32, used by OLE, DirectX, and other software.
• Also used by MacroMedia MOA, AutoDesk 3D Studio Max, and mTropolis's mFactory MOM.
• Here's IBM's inaccurate comparison of SOM and COM: http://www.austin.ibm.com/developer/objects/SOM_vs_COM_Summ.html
• Here's Don Box's response to that nonsense: http://www.develop.com/COM_vs_SOM_Summ.htm
• COM is the cornerstone of OLE's infrastructure, which provides higher level services, including:
  • Structured Storage
  • Data Transfer
  • Naming and Binding
• Many modern third-party plug-in interfaces are using COM.
  • MacroMedia Studio Xtras plug-in interface
  • AutoDesk 3D Studio Max plug-in interface
  • Maxis SimCity plug-in prototype
  • Microsoft Windows 95 MFC, OLE, OLE Controls, DirectX, Internet Explorer, DAO, and other Microsoft software components.
• One object can support multiple interfaces.
• Support for aggregation of multiple objects.
• Interfaces are C++ "vtables": tables of pointers to functions.
• IUnknown interface: the base class of COM.
  • Reference counting: AddRef, Release
  • Retrieving other available interfaces: QueryInterface
• COM interfaces are statically typed, so the compiler enforces type safety. At run time, you call QueryInterface to dynamically bind to a whole interface at once, that you can then use with no run-time penalty, since interfaces are as efficient as C++ vtables, which is how they're implemented.
• The latest version of Distributed COM in Windows NT 4.0 has Distributed Object support. Dynamic Invocation Interfaces went remote in September 1995 with the release of Remote Automation, which leverages much of the security and protocol independence of DCE RPC. Complete infrastructure services and OS integration will be provided in the Cairo release of Windows NT sometime in 1996 (beta). COM supports both the pure CORBA marshaling architecture, where objects are marshaled by reference using proxys and stubs, as well as marshaling through subcontract, where the object (not the interface) can specify its own unique distributional characteristics transparently to the client.
• Interface maps: a framework for defining interfaces used by MFC and OLE. This is MFC's implementation of COM.
  • Like Message Handler "message maps" and OLE Automation "dispatch maps".
  • Uses the standard implementation of IUnknown, built into the MFC CCmdTarget class.
  • Handles maintenance of the refcount, modified by AddRef and Release.
  • Data driven implementation of QueryInterface.
  • Support for creating aggregatable COM objects.
  • Support for using aggregate objects in the implementation of a COM object.
  • The implementation is hookable and extensible.
  • Possible to implement multiple interfaces with nested classes in C++.
  • MFC's implementation uses nested classes to define each interface implementation much like the example given. Made easier with a standard implementation of IUnknown as well as a number of macros that eliminate some repetitive code.
  • Example interface map macros used in class definition:
    

    class CPrintEditObj : public CCmdTarget { public: // member data and
    functions protected: // interface maps DECLARE_INTERFACE_MAP() BEGIN_INTERFACE_PART(EditObj,
    IEditInterface) STDMETHOD_ (void, EditObject)(); END_INTERFACE_PORT(EditObj)
    BEGIN_INTERFACE_PART(PrintObj, IPrintInterface) STDMETHOD_ (void, PrintObject)();
    END_INTERFACE_PART(PrintObj) };

  • The framework fully supports inheriting an interface map from a base class. That is why BEGIN_INTERFACE_MAP takes as its second parameter the name of the base class.
  • Note: it is not possible to reuse the implementation of MFC's built-in implementations of the OLE interfaces by inheriting the embedded specializations of that interface from the MFC version. Whatever that means. You can, however, delegate to the MFC implementation for all of the functions that you want MFC's default behavior. This design reduces the runtime size of objects which implement many interfaces, eliminating the need for a back pointer.
  • Instead of having macros that automatically generate the implementation code of these protocols, the wizard expands the code manually, so it's easier to set breakpoints and debug it. Otherwise, the macro is all on one line and you can't expand it or step through it.
  • Aggregation
    • Tie the aggregate into the QueryInterface mechanism, so the aggregate behaves as though it is a native part of your object.
    • INTERFACE_AGGREGATE macro specifies a member variable which is to be integrated into the interface map mechanism. If the pointer is not NULL when CCmdTarget::ExternalQueryInterface is called, the framework will automatically call the aggregate's QueryInterface member function, if the object itself doesn't support the requested interface.
    • For an object to be aggregatable, the implementation of AddRef, Release, and QueryInterface must delegate to the "controlling unknown".
• Here's COMBind, a set of C++ templates and stuff that make it alot easier to work with COM, by Don Box: http://www.develop.com/combind.htm