Component Object Model

MSRPC

The COM IDL is based on the feature-rich DCE/RPC IDL, with object-oriented extensions. Microsoft's implementation of DCE/RPC, MSRPC, is used as the primary inter-process communication mechanism for Windows NT services and internal components, making it an obvious choice of foundation.

DCOM

DCOM extends 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.

COM+

Microsoft introduced Microsoft Transaction Server (MTS) in Windows NT 4 in order 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.

Renamed to COM+ in Windows 2000, the feature set was incorporated into the operating system as opposed to the series of external tools provided by MTS. At the same time, Microsoft de-emphasized DCOM as a separate entity. Components that used COM+ 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 included Component Services control panel updates for configuring 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.

.NET

.NET is Microsoft's component technology that supersedes COM. .NET hides many details of component creation and therefore eases development.

.NET provides wrappers to commonly used COM controls.

.NET can leverage COM+ via the System.EnterpriseServices namespace, and several of the services that COM+ provides have been duplicated in .NET. For example, the System.Transactions namespace provides the TransactionScope class, which provides transaction management without resorting to COM+. Similarly, queued components can be replaced by Windows Communication Foundation (WCF) with an MSMQ transport.

There is limited support for backward compatibility. A COM object may be used in .NET by implementing a Runtime Callable Wrapper (RCW).^[11] NET objects that conform to certain interface restrictions may be used in COM objects by calling a COM callable wrapper (CCW).^[12] From both the COM and .NET sides, objects using the other technology appear as native objects. See COM Interop.

WCF 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.

Windows Runtime

Windows Runtime (WinRT) is a COM-based API, albeit an enhanced COM variant. Because of its COM-like basis, WinRT supports interfacing from multiple programming contexts, but it is an unmanaged, native API. The API definitions are 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 metadata format allows for significantly lower overhead than P/Invoke when WinRT is invoked from .NET applications.

Nano-COM

Nano-COM is a subset of COM focused 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 in a portable C++ header file. Nano-COM extends the native ABI of the underlying instruction architecture and OS to support typed object references – whereas a typical ABI focuses on atomic types, structures, arrays and function calling conventions.

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

• GUID – identifies an interface type

• HRESULT – method result codes such as S_OK, E_FAIL, E_OUTOFMEMORY

• IUnknown – base type for object references; 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 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 when 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).

Nano-COM is currently in use as the base ABI technology for DirectX/Direct3D/DirectML.

In Internet Explorer

Since an ActiveX control (any COM component) runs as native code, with no sandboxing protection, there are few restrictions on what it can do. Using ActiveX components, as Internet Explorer supported, in a web page lead to problems with malware infections. Microsoft recognized the problem as far back as 1996 when Charles Fitzgerald said, "We never made the claim up front that ActiveX is intrinsically secure".^[13] Later versions of Internet Explorer prompt the user before installing an ActiveX control, allowing them to block installation.

As a level of protection, an ActiveX control is signed with a digital signature to guarantee authenticity.

It is also possible to disable ActiveX controls altogether, or to allow only a selected few.

Process corruption

The transparent support for out-of-process COM servers promotes software safety in terms of process isolation. This can be useful for decoupling subsystems of large application into separate processes. Process isolation limits state corruption in one process from negatively affecting the integrity of the other processes, since they only communicate through strictly defined interfaces. Thus, only the affected subsystem needs to be restarted in order to regain valid state. This is not the case for subsystems within the same process, where a rogue pointer in one subsystem can randomly corrupt other subsystems.

Coclass

A coclass, a COM class, implements one or more interfaces. It is identified by a class ID, called CLSID which is GUID, and by a human-readable programmatic identifier, called ProgID. A coclass is created via one of these identifiers.

Interface

Each COM interface extends the IUnknown interface, which exposes methods for reference counting and for accessing the other interfaces of the object – similar to type conversion, a.k.a. type casting.

An interface is identified by an interface ID (IID), a GUID.

A custom interface, anything derived from IUnknown, provides early bound access via 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 order they are declared. An in-process invocation overhead is, therefore, comparable to a C++ virtual method call.

Dispatching, a.k.a. late bound access, is provided by implementing IDispatch. Dispatching allows access from a wider range of programming contexts than a custom interface.

Like many object-oriented languages, COM provides a separation of interface from implementation. This distinction is especially strong in COM where an object has no default interface. A client must request an interface to have any access. COM supports multiple implementations of the same interface, so that clients can choose which implementation of an interface to use.

Type library

A COM type library defines COM metadata, such as coclasses and interfaces. A library can be defined as Interface definition language (IDL); a programming language independent syntax. IDL is similar to C++ with additional syntax for defining interfaces and coclasses. IDL also supports bracketed attributes before declarations to define metadata such as identifiers and relationships between parameters.

An IDL file is compiled via the MIDL compiler. For use with C/C++, the MIDL compiler generates a header file with 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.

MIDL can generate a binary type library (TLB) that can be used by other tools to support access from other context.

Examples

The following IDL code declares a coclass named SomeClass which implements an interface named ISomeInterface.

coclass SomeClass {
  [default] interface ISomeInterface;
};

This is conceptually equivalent to the following C++ code where ISomeInterface is a pure virtual class, a.k.a. abstract base class.

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

In C++, COM objects are instantiated via the COM subsystem CoCreateInstance function that takes the CLSID and IID. SomeClass can be created as follows:

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

Complexity

COM is relatively complex especially compared to more modern component technologies such as .NET.

Message pumping

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.^[30]

Reference counting

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.^[31]

DLL Hell

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.