Component Object Model


Component Object Model is a binary-interface technology for software components from Microsoft that enables using objects in a language-neutral way between different programming languages, programming contexts, processes and machines.
COM is the basis for other Microsoft domain-specific component technologies including OLE, OLE Automation, ActiveX, COM+, and DCOM as well as implementations such as DirectX, Windows shell, UMDF, Windows Runtime, and Browser Helper Object.
COM enables object use when only the object's interface is known, not its internal implementation. The component implementer defines interfaces that are separate from the implementation.
Support for multiple programming contexts is handled by relying on the object for aspects that would be challenging to implement as a facility. Supporting multiple uses of an object is handled by requiring each object to destroy itself via reference-counting. Access to an object's interfaces is provided by each object as well.
COM is available only in Microsoft Windows and Apple's Core Foundation 1.3 and later plug-in application programming interface. The latter only implements a subset of the whole COM interface.
Over time, COM is being replaced with other technologies such as Microsoft.NET and web services. However, COM objects can be used in a.NET language via COM Interop.
COM is similar to other component technologies such as SOM, CORBA and Enterprise JavaBeans, although each has its strengths and weaknesses.
Unlike C++, COM provides a stable application binary interface that is unaffected by compiler differences. This makes using COM advantageous for object-oriented C++ libraries that are to be used by clients compiled via different compilers.

History

Introduced in 1987, Dynamic Data Exchange was one of the first interprocess communication technologies in Windows. It allowed sending and receiving messages in so-called conversations between applications.
Tony Williams, involved in architecting COM, distributed two papers within Microsoft that embraced the concept of software components: Object Architecture: Dealing With the Unknown – or – Type Safety in a Dynamically Extensible Class Library in 1988 and On Inheritance: What It Means and How To Use It in 1990. These provided the foundation of many of the ideas behind COM.
Object Linking and Embedding, Microsoft's first object-based framework, was built on DDE and designed specifically for compound documents. It was introduced with Word and Excel in 1991, and was later included with Windows, starting with version 3.1 in 1992. An example of a compound document is a spreadsheet embedded in a Word document. As changes are made to the spreadsheet in Excel, they appear automatically in the Word document.
In 1991, Microsoft introduced the Visual Basic Extension technology with Visual Basic 1.0. A VBX is a packaged extension in the form of a dynamic-link library that allows objects to be graphically placed in a form and manipulated by properties and methods. These were later adapted for use by other languages such as Visual C++. Windows 3.1 integrated OLE 1.0.
In 1992, Microsoft released OLE 2 with its new underlying object model, COM. The COM application binary interface was the same as the MAPI ABI, and like it was based on MSRPC and ultimately on the Open Group's DCE/RPC. COM was created to replace DDE since its text-based conversation and Windows messaging design was not flexible enough to allow sharing application features in a robust and extensible way. The COM introduced UUID as identifier.
In 1994, the OLE custom control technology, based on COM, was introduced as the successor to VBX. At the same time, Microsoft stated that OLE 2 would be known simply as "OLE". Windows NT 3.5 and Windows 95 integrated OLE 2.0.
In early 1996, Microsoft found a new use for OCX extending their web browser's capability. Microsoft renamed some parts of OLE relating to the Internet as ActiveX, and gradually renamed all OLE technologies to ActiveX, except the compound document technology that was used in Microsoft Office.
Later in 1996, Microsoft extended COM to work across the network with DCOM.

Related technologies

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 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 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. 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 with components called Queued Components. COM+ events extend the COM+ programming model to support late-bound 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 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. NET objects that conform to certain interface restrictions may be used in COM objects by calling a COM callable wrapper. 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 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 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-style acquisition of new interface types and ref counting a la shared_ptr
Many uses of Nano-COM define two functions to address callee-allocated memory buffers as results:
  • Alloc called by method implementations to allocate raw buffers that are returned to the caller
  • 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.
Nano-COM is currently in use as the base ABI technology for DirectX/Direct3D/DirectML.