Component Object Model

COM replaced DDE as the preferred form of interprocess communication.

As a cross-language component model, COM relies on an interface definition language, or IDL, to describe the objects and associated functions. The COM IDL is based heavily on the feature-rich DCE/RPC IDL, with object-oriented extensions. Microsoft's own implementation of DCE/RPC, known as MSRPC, is heavily used as the primary inter-process communication mechanism for Windows NT services and internal components, making it an obvious choice of foundation.

DCOM (Distributed COM) extended the reach of COM from merely supporting a single user with separate applications communicating on the Windows desktop, to activating objects running under different security contexts, and on different machines across the network. With this were added necessary features for configuring which users have authority to create, activate and call objects, for identifying the calling user, as well as specifying required encryption for security of calls.

In order for Microsoft to provide developers with support for distributed transactions, resource pooling, disconnected applications, event publication and subscription, better memory and processor (thread) management, as well as to position Windows as an alternative to other enterprise-level operating systems, Microsoft introduced a technology called Microsoft Transaction Server (MTS) on Windows NT 4. With Windows 2000, that significant extension to COM was incorporated into the operating system (as opposed to the series of external tools provided by MTS) and renamed COM+. At the same time, Microsoft de-emphasized DCOM as a separate entity. Components that made use of COM+ services were handled more directly by the added layer of COM+, in particular by operating system support for interception. In the first release of MTS, interception was tacked on - installing an MTS component would modify the Windows Registry to call the MTS software, and not the component directly. Windows 2000 also revised the Component Services control panel application used to configure COM+ components.

An advantage of COM+ was that it could be run in "component farms". Instances of a component, if coded properly, could be pooled and reused by new calls to its initializing routine without unloading it from memory. Components could also be distributed (called from another machine). COM+ and Microsoft Visual Studio provided tools to make it easy to generate client-side proxies, so although DCOM was used to make the remote call, it was easy to do for developers. COM+ also introduced a subscriber/publisher event mechanism called COM+ Events, and provided a new way of leveraging MSMQ (a technology that provides inter-application asynchronous messaging) with components called Queued Components. COM+ events extend the COM+ programming model to support late-bound (see Late binding) events or method calls between the publisher or subscriber and the event system.

Microsoft .NET provides means both to provide component technology, and to interact with COM+ (via COM-interop-assemblies); .NET provides wrappers to most of the commonly used COM controls. Microsoft .NET hides most detail from component creation and therefore eases development. .NET can leverage COM+ via the System.EnterpriseServices namespace, and several of the services that COM+ provides have been duplicated in recent releases of .NET. For example, the System.Transactions namespace in .NET provides the TransactionScope class, which provides transaction management without resorting to COM+. Similarly, queued components can be replaced by Windows Communication Foundation with an MSMQ transport. (MSMQ is a native COM component, however.) There is limited support for backward compatibility. A COM object may be used in .NET by implementing a Runtime Callable Wrapper (RCW).[7] NET objects that conform to certain interface restrictions may be used in COM objects by calling a COM callable wrapper (CCW).[8] From both the COM and .NET sides, objects using the other technology appear as native objects. See COM Interop. WCF (Windows Communication Foundation) eases a number of COM's remote execution challenges. For instance, it allows objects to be transparently marshalled by value across process or machine boundaries more easily.

Microsoft's Windows Runtime (or WinRT, not to be confused with Windows RT) programming and application model is essentially a COM-based API, although it relies on an enhanced COM. Because of its COM-like basis, Windows Runtime allows relatively easy interfacing from multiple languages, just as COM does, but it is essentially an unmanaged, native API. The API definitions are, however, stored in ".winmd" files, which are encoded in ECMA 335 metadata format, the same CLI metadata format that .NET uses with a few modifications. This common metadata format allows for significantly less overhead than P/Invoke when WinRT is invoked from .NET applications, and its syntax is much simpler.

Nano-COM is an extremely small subset of the Component Object Model that is focused exclusively on the Application Binary Interface (ABI) aspects of COM that enable function and method calls across independently compiled modules/components. Nano-COM can be expressed easily in a single C++ header file that is portable to all C++ compilers. Nano-COM extends the native ABI of the underlying instruction architecture and OS to add support for typed object references (typical ABIs focus only on atomic types, structures, arrays and function calling conventions). The basis of Nano-COM was used by Mozilla to bootstrap Firefox (called XPCOM), and is currently in use as the base ABI technology for DirectX/Direct3D/DirectML.

A Nano-COM header file defines or names at least three types:

• GUID to identify interface types - this is effectively a 128 bit number
• HRESULT to identify error codes from method calls - this is effectively a standardized usage of 32-bit ints to well known values (S_OK, E_FAIL, E_OUTOFMEMORY, etc)
• IUnknown as the base type for all typed object references - this is effectively abstract virtual functions to support dynamic_cast<T>-style acquisition of new interface types and ref counting a la shared_ptr<T>

Many uses of Nano-COM also define two functions to address callee-allocated memory buffers as results

• <NanoCom>Alloc – called by method implementations to allocate raw buffers (not objects) that are returned to the caller
• <NanoCom>Free – called by method callers to free callee-allocated buffers once no longer in use

Some implementations of Nano-COM such as Direct3D eschew the allocator functions and restrict themselves to only use caller-allocated buffers.

Nano-COM has no notion of classes, apartments, marshaling, registration, etc. Rather, object references are simply passed across function boundaries and allocated via standard language constructs (e.g., C++ new operator).

All COM components implement the IUnknown (custom) interface, which exposes methods for reference counting and type conversion (casting). A custom IUnknown interface consists of a pointer to a virtual method table that contains a list of pointers to the functions that implement the functions declared in the interface, in the same order that they are declared in the interface. The in-process invocation overhead is therefore comparable to virtual method calls in C++. In addition to custom interfaces, COM also supports dispatch interfaces inheriting from IDispatch. Dispatch interfaces support late binding for OLE Automation. This allows dispatch interfaces to be natively accessed from a wider range of programming languages than custom interfaces.

A COM class ("coclass") is a concrete implementation of one or more interfaces, and closely resembles classes in object-oriented programming languages. Classes are created based on their class ID (CLSID) or based on their programmatic identifier string (ProgID). Like many object-oriented languages, COM provides a separation of interface from implementation. This distinction is especially strong in COM, where objects cannot be accessed directly, but only through their interfaces. COM also has support for multiple implementations of the same interface, so that clients at runtime can choose which implementation of an interface to instantiate.

Type libraries contain metadata to represent COM types. These types are described using Microsoft Interface Definition Language (MSIDL/IDL). IDL files define object-oriented classes, interfaces, structures, enumerations and other user-defined types in a language independent manner. IDL is similar in appearance to C++ declarations with some additional keywords such as "interface" and "library" for defining interfaces and collections of classes. IDL also supports the use of bracketed attributes before declarations to provide additional information, such as interface GUIDs and the relationships between pointer parameters and length fields. IDL files are compiled by the MIDL compiler. For C/C++, the MIDL compiler generates a compiler-independent header file containing struct definitions to match the vtbls of the declared interfaces and a C file containing declarations of the interface GUIDs. C++ source code for a proxy module can also be generated by the MIDL compiler. This proxy contains method stubs for converting COM calls into remote procedure calls to enable DCOM for out-of-process communication. IDL files can also be compiled by the MIDL compiler into a type library (TLB). TLB files contain binary metadata that can be processed by different language compilers and runtime environments (e.g. VB, Delphi, .NET etc.) to generate language-specific constructs to represent the COM types defined in the TLB. For C++, this will convert the TLB back to its IDL representation.

Because COM is a runtime framework, types have to be individually identifiable and specifiable at runtime. To achieve this, globally unique identifiers (GUIDs) are used. Each COM type is designated its own GUID for identification at runtime. In order for information on COM types to be accessible at both compile time and runtime, COM uses type libraries. It is through the effective use of type libraries that COM achieves its capabilities as a dynamic framework for the interaction of objects.

Consider the following example coclass definition in an IDL:

coclass SomeClass {
  [default] interface ISomeInterface;
};

The above code fragment declares a COM class named SomeClass which implements an interface named ISomeInterface.

This is conceptually equivalent to defining the following C++ class:

class SomeClass : public ISomeInterface {
  ...
  ...
};

where ISomeInterface is a C++ pure virtual class (sometimes called an abstract base class).

The IDL files containing COM interfaces and classes are compiled into type libraries (TLB) files, which can later be parsed by clients at runtime to determine which interfaces an object supports, and invoke an object's interface methods.

In C++, COM objects are instantiated with the CoCreateInstance function that takes the class ID (CLSID) and interface ID (IID) as arguments. Instantiation of SomeClass can be implemented as follows:

ISomeInterface* interface_ptr = NULL;
HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL,
                              IID_ISomeInterface, (void**)&interface_ptr);

In this example, the COM sub-system is used to obtain a pointer to an object that implements ISomeInterface interface, and coclass CLSID_SomeClass's particular implementation of this interface is required.

All COM objects utilize reference counting to manage object lifetimes. The reference counts are controlled by the clients through the AddRef and Release methods in the mandatory IUnknown interface that all COM objects implement. COM objects are then responsible for freeing their own memory when the reference count drops to zero. Certain languages (e.g. Visual Basic) provide automatic reference counting so that COM object developers need not explicitly maintain any internal reference counter in their source codes. In C++, a coder may either perform explicit reference counting or use smart pointers to automatically manage the reference counts.

The following are guidelines for when to call AddRef and Release on COM objects:

• Functions and methods that return interface references (via return value or via "out" parameter) shall increment the reference count of the returned object before returning.
• Release must be called on an interface pointer before the pointer is overwritten or goes out of scope.
• If a copy is made on an interface reference pointer, AddRef should be called on that pointer.
• AddRef and Release must be called on the specific interface which is being referenced since an object may implement per-interface reference counts in order to allocate internal resources only for the interfaces which are being referenced.

Not all reference count calls are sent to remote objects over the wire; a proxy keeps only one reference on the remote object and maintains its own local reference count. To simplify COM development, Microsoft introduced ATL (Active Template Library) for C++ developers. ATL provides for a higher-level COM development paradigm. It also shields COM client application developers from the need to directly maintain reference counting, by providing smart pointer objects. Other libraries and languages that are COM-aware include the Microsoft Foundation Classes, the VC Compiler COM Support,[12] VBScript, Visual Basic, ECMAScript (JavaScript) and Borland Delphi.

COM is a language agnostic binary standard that can be developed in any programming language capable of understanding and implementing its binary defined data types and interfaces. COM implementations are responsible for entering and leaving the COM environment, instantiating and reference-counting COM objects, querying objects for supported interfaces, as well as handling errors. The Microsoft Visual C++ compiler supports extensions to the C++ language referred to as C++ Attributes.[13] These extensions are designed to simplify COM development and remove much of the boilerplate code required to implement COM servers in C++.[14]

In Windows, COM classes, interfaces and type libraries are listed by GUIDs in the registry, under HKEY_CLASSES_ROOT\CLSID for classes and HKEY_CLASSES_ROOT\Interface for interfaces. COM libraries use the registry to locate either the correct local libraries for each COM object or the network location for a remote service.

Registration-Free COM (RegFree COM) is a technology introduced with Windows XP that allows Component Object Model (COM) components to store activation metadata and CLSID (Class ID) for the component without using the registry. Instead, the metadata and CLSIDs of the classes implemented in the component are declared in an assembly manifest (described using XML), stored either as a resource in the executable or as a separate file installed with the component.[15] This allows multiple versions of the same component to be installed in different directories, described by their own manifests, as well as XCOPY deployment.[16] This technique has limited support for EXE COM servers[17] and cannot be used for system-wide components such as MDAC, MSXML, DirectX or Internet Explorer.

During application loading, the Windows loader searches for the manifest.[18] If it is present, the loader adds information from it to the activation context.[16] When the COM class factory tries to instantiate a class, the activation context is first checked to see if an implementation for the CLSID can be found. Only if the lookup fails, the registry is scanned.[16]

COM objects can also be created manually, given the path of the DLL file and GUID of the object. This does not require the DLL or GUID to be registered in the system registry, and does not make use of manifest files. A COM DLL exports a function named DllGetClassObject. Calling DllGetClassObject with the desired GUID and IID_IClassFactory provides an instance of a factory object. The Factory object has a CreateInstance method, which can create instances of an object given an interface GUID.[19] This is the same process internally used when creating instances of registered COM components.[20]

If the created COM object instantiates another COM object using the generic CoCreateInstance API, it will try to do so in the usual generic way, using the registry or manifest files. But it can create internal objects (which may not be registered at all), and hand out references to interfaces to them, using its own private knowledge.

COM objects can be transparently instantiated and referenced from within the same process (in-process), across process boundaries (out-of-process), or remotely over the network (DCOM). Out-of-process and remote objects use marshalling to serialize method calls and return values over process or network boundaries. This marshalling is invisible to the client, which accesses the object as if it were a local in-process object.

In COM, threading is addressed through a concept known as apartments.[21] An individual COM object lives in exactly one apartment, which might either be single-threaded or multi-threaded. There are three types of apartments in COM: Single-Threaded Apartment (STA), Multi-Threaded Apartment (MTA), and Thread Neutral Apartment (NA). Each apartment represents one mechanism whereby an object's internal state may be synchronized across multiple threads. A process can consist of multiple COM objects, some of which may use STA and others of which may use MTA. All threads accessing COM objects similarly live in one apartment. The choice of apartment for COM objects and threads are determined at run-time, and cannot be changed.

Threads and objects which belong to the same apartment follow the same thread access rules. Method calls which are made inside the same apartment are therefore performed directly without any assistance from COM. Method calls made across apartments are achieved via marshalling. This requires the use of proxies and stubs.

When an STA is initialized it creates a hidden window that is used for inter-apartment and inter-process message routing. This window must have its message queue regularly "pumped". This construct is known as a "message pump". On earlier versions of Windows, failure to do so could cause system-wide deadlocks. This problem is complicated by some Windows APIs that initialize COM as part of their implementation, which causes a "leak" of implementation details.

Reference counting within COM may cause problems if two or more objects are circularly referenced. The design of an application must take this into account so that objects are not left orphaned. Objects may also be left with active reference counts if the COM "event sink" model is used. Since the object that fires the event needs a reference to the object reacting to the event, the latter's reference count will never reach zero. Reference cycles are typically broken using either out-of-band termination or split identities. In the out-of-band termination technique, an object exposes a method which, when called, forces it to drop its references to other objects, thereby breaking the cycle. In the split identity technique, a single implementation exposes two separate COM objects (also known as identities). This creates a weak reference between the COM objects, preventing a reference cycle.

Because in-process COM components are implemented in DLL files and registration only allows for a single version per CLSID, they might in some situations be subject to the "DLL Hell" effect. Registration-free COM capability eliminates this problem for in-process components; registration-free COM is not available for out-of-process servers.