Component Object Model

Component Object Model (COM) is a binary-interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication object creation in a large range of programming languages. COM is the basis for several other Microsoft technologies and frameworks, including OLE, OLE Automation, Browser Helper Object, ActiveX, COM+, DCOM, the Windows shell, DirectX, UMDF and Windows Runtime. The essence of COM is a language-neutral way of implementing objects that can be used in environments different from the one in which they were created, even across machine boundaries. For well-authored components, COM allows reuse of objects with no knowledge of their internal implementation, as it forces component implementers to provide well-defined interfaces that are separated from the implementation. The different allocation semantics of languages are accommodated by making objects responsible for their own creation and destruction through reference-counting. Type conversion casting between different interfaces of an object is achieved through the QueryInterface method. The preferred method of "inheritance" within COM is the creation of sub-objects to which method "calls" are delegated.

COM is an interface technology defined and implemented as standard only on Microsoft Windows and Apple's Core Foundation 1.3 and later plug-in application programming interface (API).[1] The latter only implements a subset of the whole COM interface.[2] For some applications, COM has been replaced at least to some extent by the Microsoft .NET framework, and support for Web Services through the Windows Communication Foundation (WCF). However, COM objects can be used with all .NET languages through .NET COM Interop. Networked DCOM uses binary proprietary formats, while WCF encourages the use of XML-based SOAP messaging. COM is very similar to other component software interface technologies, such as CORBA and Enterprise JavaBeans, although each has its own strengths and weaknesses. Unlike C++, COM provides a stable application binary interface (ABI) that does not change between compiler releases.[3] This makes COM interfaces attractive for object-oriented C++ libraries that are to be used by clients compiled using different compiler versions.


One of the first methods of interprocess communication in Windows was Dynamic Data Exchange (DDE), first introduced in 1987, that allowed sending and receiving messages in so-called "conversations" between applications. Antony Williams involved in the creation of the COM architecture, later distributed two internal papers in 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 (OLE), Microsoft's first object-based framework, was built on top of DDE and designed specifically for compound documents. It was introduced with Word for Windows 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 for Windows document: as changes are made to the spreadsheet within Excel, they appear automatically inside the Word document.

In 1991, Microsoft introduced Visual Basic Extensions (VBX) with Visual Basic 1.0. A VBX is a packaged extension in the form of a dynamic-link library (DLL) 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++. In 1992, when version 3.1 of Windows was released, Microsoft released OLE 2 with its underlying object model. The COM Application binary interface (ABI) was the same as the MAPI ABI (released in 1992), and like it was based on MSRPC and ultimately on the Open Group's DCE/RPC. While OLE 1 was focused on compound documents, COM and OLE 2 were designed to address software components in general. Text conversations and Windows messages had proved not to be flexible enough to allow sharing application features in a robust and extensible way, so COM was created as a new foundation, and OLE changed to OLE2. In 1994 OLE custom controls (OCXs) were introduced as the successor to VBX controls. At the same time, Microsoft stated that OLE 2 would just be known as "OLE", and that OLE was no longer an acronym, but a name for all of the company's component technologies. In early 1996, Microsoft found a new use for OLE Custom Controls, expanding their Web browser's capability to present content, renamed some parts of OLE relating to the Internet "ActiveX", and gradually renamed all OLE technologies to ActiveX, except the compound document technology that was used in Microsoft Office. Later that year, DCOM was introduced as an answer to CORBA.

Related technologies

COM was the major software development platform for Windows and, as such, influenced development of a number of supporting technologies. It was likewise heavily influenced by earlier technologies.


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 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).[4] NET objects that conform to certain interface restrictions may be used in COM objects by calling a COM callable wrapper (CCW).[5] 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.

Windows Runtime

Microsoft's new 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.


COM and ActiveX components are run as native code on the user's machine, with no sandboxing. There are therefore few restrictions on what the code can do. The prior practice of embedding ActiveX components on web pages with Internet Explorer did therefore lead to problems with malware infections. Microsoft recognized the problem with ActiveX as far back as 1996 when Charles Fitzgerald said, "We never made the claim up front that ActiveX is intrinsically secure".[6] Recent versions of Internet Explorer prompt the user before installing ActiveX controls, enabling the user to disallow installation of controls from sites that the user does not trust. The ActiveX controls are signed with digital signatures to guarantee their authenticity. It is also possible to disable ActiveX controls altogether, or to allow only a selected few. The transparent support for out-of-process COM servers still 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.

Technical details

COM programmers build their software using COM-aware components. Different component types are identified by class IDs (CLSIDs), which are Globally Unique Identifiers (GUIDs). Each COM component exposes its functionality through one or more interfaces. The different interfaces supported by a component are distinguished from each other using interface IDs (IIDs), which are GUIDs too. COM interfaces have bindings in several languages, such as C, C++, Visual Basic, Delphi, Python[7][8] and several of the scripting languages implemented on the Windows platform. All access to components is done through the methods of the interfaces. This allows techniques such as inter-process, or even inter-computer programming (the latter using the support of DCOM).


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.

Interface Definition Language and type libraries

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.

COM as an object framework

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.

Reference counting

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,[9] 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.[10] These extensions are designed to simplify COM development and remove much of the plumbing code required to implement COM servers in C++.[11]

Registry usage

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

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.[12] This allows multiple versions of the same component to be installed in different directories, described by their own manifests, as well as XCOPY deployment.[13] This technique has limited support for EXE COM servers[14] 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.[15] If it is present, the loader adds information from it to the activation context.[13] 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 is the registry scanned.[13]

Manually instantiating COM objects

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.[16] This is the same process internally used when creating instances of registered COM components.[17]

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.

Process and network transparency

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.[18] 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.

Apartment type Description
Single-Threaded Apartment[19] (STA), (ThreadingModel=Apartment) A single thread is dedicated to execute the methods of the object. In such an arrangement, method calls from threads outside of the apartment are marshalled and automatically queued by the system (via a standard Windows message queue). Thus, the COM run-time provides automatic synchronization to ensure that each method call of an object is always executed to completion before another is invoked. The developer therefore does not need to worry about thread locking or race conditions.
Multi-Threaded Apartment[20] (MTA), (ThreadingModel=Free) The COM run-time provides no synchronization, and multiple threads are allowed to call COM objects simultaneously. COM objects therefore need to perform their own synchronization to prevent simultaneous access from multiple threads from causing a race condition. Calls to an MTA object from a thread in an STA are also marshalled.
Dynamically determined apartment (ThreadingModel=Both) In the Both apartment mode, the server auto-selects STA or MTA at object creation to match the apartment type of the calling thread.[21] This can be useful to avoid marshaling overhead when MTA servers are accessed by a STA thread.
Thread Neutral Apartment (NA), (ThreadingModel=Neutral) A special apartment without any assigned threads. When a STA or MTA thread calls a NA object in the same process, then the calling thread temporarily leaves its apartment and executes code directly in the NA without any thread switching.[22] Therefore, one can think of NA as an optimization for efficient interapartment method calls.

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.


Since COM has a fairly complex implementation, programmers can be distracted by some of the "plumbing" issues.

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.

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.

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.

See also


  1. ^ "Documentation Archive".
  2. ^ "Plug-ins and Microsoft's COM". Apple Inc. Retrieved October 5, 2010.
  3. ^ Microsoft forum: Binary compatibility across Visual C++ versions
  4. ^ rpetrusha. "Runtime Callable Wrapper".
  5. ^ rpetrusha. "COM Callable Wrapper".
  6. ^ "Competing components make for prickly panelists". August 10, 2006.
  7. ^ "win32com Documentation Index".
  8. ^ "Python and COM".
  9. ^ "Compiler COM Support". MSDN. Microsoft.
  10. ^ Microsoft MSDN: C++ Attributes Reference
  11. ^ MSDN Magazine: C++ Attributes: Make COM Programming a Breeze with New Feature in Visual Studio .NET
  12. ^ "Assembly Manifests". MSDN. Retrieved November 5, 2009.
  13. ^ a b c Dave Templin. "Simplify App Deployment with ClickOnce and Registration-Free COM". MSDN Magazine. Retrieved April 22, 2008.
  14. ^ "How to use an out-of-process COM server without its tlb file". Retrieved April 16, 2011.
  15. ^ "Concepts of Isolated Applications and Side-by-side Assemblies". MSDN. Retrieved February 5, 2016.
  16. ^ Arkhipov, Mikhail (April 1, 2005). "Registration-free COM". MSDN Blogs. Retrieved April 29, 2016.
  17. ^ "DllGetClassObject entry point (COM)". MSDN. If a call to the CoGetClassObject function finds the class object that is to be loaded in a DLL, CoGetClassObject uses the DLL's exported DllGetClassObject function.
  18. ^ Microsoft MSDN: Processes, Threads, and Apartments
  19. ^ Microsoft MSDN: Single-Threaded Apartments
  20. ^ Microsoft MSDN: Multithreaded Apartments
  21. ^ Microsoft MSDN: Understanding and Using COM Threading Models
  22. ^ Codeguru: Understanding COM Apartments


External links

.NET Remoting

.NET Remoting is a Microsoft application programming interface (API) for interprocess communication released in 2002 with the 1.0 version of .NET Framework. It is one in a series of Microsoft technologies that began in 1990 with the first version of Object Linking and Embedding (OLE) for 16-bit Windows. Intermediate steps in the development of these technologies were Component Object Model (COM) released in 1993 and updated in 1995 as COM-95, Distributed Component Object Model (DCOM), released in 1997 (and renamed Active X), and COM+ with its Microsoft Transaction Server (MTS), released in 2000. It is now superseded by Windows Communication Foundation (WCF), which is part of the .NET Framework 3.0.

Like its family members and similar technologies such as Common Object Request Broker Architecture (CORBA) and Java's remote method invocation (RMI), .NET Remoting is complex, yet its essence is straightforward. With the assistance of operating system and network agents, a client process sends a message to a server process and receives a reply.

ActiveX Data Objects

In computing, Microsoft's ActiveX Data Objects (ADO) comprises a set of Component Object Model (COM) objects for accessing data sources. A part of MDAC (Microsoft Data Access Components), it provides a middleware layer between programming languages and OLE DB (a means of accessing data stores, whether databases or not, in a uniform manner). ADO allows a developer to write programs that access data without knowing how the database is implemented; developers must be aware of the database for connection only. No knowledge of SQL is required to access a database when using ADO, although one can use ADO to execute SQL commands directly (with the disadvantage of introducing a dependency upon the type of database used).

Microsoft introduced ADO in October 1996, positioning the software as a successor to Microsoft's earlier object layers for accessing data sources, including RDO (Remote Data Objects) and DAO (Data Access Objects).

ADO is made up of four collections and twelve objects.

ActiveX Document

ActiveX Document (also known as DocObject or DocObj) is a Microsoft technology that allows users to view and edit Microsoft Word, Excel, and PDF documents inside web browsers. It defines a set of Component Object Model coding contracts between hosting programs like Internet Explorer or Microsoft Office Binder and hosted documents from programs like Microsoft Word, Microsoft Excel and Adobe Reader. This allows them to negotiate communications about commands like save and navigate, as well as merging user interface elements such as menu, to provide a unified user experience.

Initially designed for compound documents based on COM Structured Storage, the technology allows one single hosting program like Office Binder to contain unlimited type of documents. The server program that provides an ActiveX document can be an EXE or a DLL server.

Active Template Library

The Active Template Library (ATL) is a set of template-based C++ classes developed by Microsoft, intended to simplify the programming of Component Object Model (COM) objects. The COM support in Microsoft Visual C++ allows developers to create a variety of COM objects, OLE Automation servers, and ActiveX controls. ATL includes an object wizard that sets up primary structure of the objects quickly with a minimum of hand coding. On the COM client side ATL provides smart pointers that deal with COM reference counting. The library makes heavy use of the curiously recurring template pattern.


CAPICOM is a discontinued ActiveX control created by Microsoft to help expose a select set of Microsoft Cryptographic Application Programming Interface (CryptoAPI) functions through Microsoft Component Object Model (COM). It was intended to enable every environment that supports ActiveX to use Microsoft Cryptographic technologies, including web pages that are opened with Microsoft Internet Explorer or any other web browser that supports ActiveX.CAPICOM can be used to digitally sign data, inspect, verify and display their digital signature or digital certificate, add or remove certificates to or from the certificate stores, and finally, to encrypt or decrypt data.CAPICOM Version, the latest and last version of CAPICOM, is officially supported on Windows Vista. However, Microsoft has announced that CAPICOM is discontinued and is no longer being developed. Microsoft suggests replacing CAPICOM with .NET Framework's X509 Cryptographic Classes and a number of other alternatives.CAPICOM was not included in Windows 7. The linked Microsoft article goes into detail.

COM Interop

COM Interop is a technology included in the .NET Framework Common Language Runtime (CLR) that enables Component Object Model (COM) objects to interact with .NET objects, and vice versa.

COM Interop aims to provide access to the existing COM components without requiring that the original component be modified. It tries to make the .NET types equivalent to the COM types. In addition, COM Interop allows COM developers to access managed objects as easily as they access other COM objects.

Core Foundation

Core Foundation (also called CF) is a C application programming interface (API) in macOS & iOS, and is a mix of low-level routines and wrapper functions. Apple releases most of it as an open-source project called CFLite that can be used to write cross-platform applications for macOS, Linux, and Windows; a third-party open-source implementation called OpenCFLite also exists. Most Core Foundation routines follow a certain naming convention that deal with opaque objects, for example CFDictionaryRef for functions whose names begin with CFDictionary, and these objects are often reference counted (manually) through CFRetain and CFRelease. Internally, Core Foundation forms the base of the types in the Objective-C standard library as well.

The most prevalent use of Core Foundation is for passing its own primitive types for data, including raw bytes, Unicode strings, numbers, calendar dates, and UUIDs, as well as collections such as arrays, sets, and dictionaries, to numerous macOS C routines, primarily those that are GUI-related. At the operating system level Core Foundation also provides standardized application preferences management through CFPropertyList, bundle handling, run loops, interprocess communication through CFMachPort and CFNotificationCenter, and a basic graphical user interface message dialog through CFUserNotification.

Other parts of the API include utility routines and wrappers around existing APIs for ease of use. Utility routines perform such actions as file system and network I/O through CFReadStream, CFWriteStream, and CFURL and endianness translation (Byte Order Utilities). Some examples of wrapper routines include those for Core Foundation's wrapper routines for Unix sockets, the CFSocket API.

Some types in Core Foundation are "toll-free bridged", or interchangeable with a simple cast, with those of their Foundation Kit counterparts. For example, one could create a CFDictionaryRef Core Foundation type, and then later simply use a standard C cast to convert it to its Objective-C counterpart, NSDictionary *, and then use the desired Objective-C methods on that object as one normally would.

Core Foundation has a plug-in model (CFPlugin) that is based on the Microsoft Component Object Model.


DirectPlay is a deprecated API that was part of Microsoft's DirectX API. DirectPlay is a network communication library intended for computer game development, although its general nature allows it to be used for other purposes.

DirectPlay is a high-level software interface between applications and communication services that makes it easy to connect games over the Internet, a modem link, or a network. DirectPlay features a set of tools that allow players to find game sessions and sites to manage the flow of information between hosts and players. It provides a way for applications to communicate with each other, regardless of the underlying online service or protocol. DirectPlay also resolves many connectivity issues, such as NAT.

DirectPlay, like the rest of DirectX, runs in COM and it is accessed through COM (Component Object Model) interfaces. By default, DirectPlay uses multi-threaded programming techniques and requires careful thought to avoid the usual threading issues. Since DirectX version 9, this issue can be alleviated at the expense of efficiency.

Distributed Component Object Model

Distributed Component Object Model (DCOM) is a proprietary Microsoft technology for communication between software components on networked computers. DCOM, which originally was called "Network OLE", extends Microsoft's COM, and provides the communication substrate under Microsoft's COM+ application server infrastructure.

The addition of the "D" to COM was due to extensive use of DCE/RPC (Distributed Computing Environment/Remote Procedure Calls) – more specifically Microsoft's enhanced version, known as MSRPC.

In terms of the extensions it added to COM, DCOM had to solve the problems of

Marshalling – serializing and deserializing the arguments and return values of method calls "over the wire".

Distributed garbage collection – ensuring that references held by clients of interfaces are released when, for example, the client process crashed, or the network connection was lost.

It had to combine Hundreds/Tens of Thousands of objects held in the client's browser with a single transmission in order to minimize bandwidth utilization.One of the key factors in solving these problems is the use of DCE/RPC as the underlying RPC mechanism behind DCOM. DCE/RPC has strictly defined rules regarding marshalling and who is responsible for freeing memory.

DCOM was a major competitor to CORBA. Proponents of both of these technologies saw them as one day becoming the model for code and service-reuse over the Internet. However, the difficulties involved in getting either of these technologies to work over Internet firewalls, and on unknown and insecure machines, meant that normal HTTP requests in combination with web browsers won out over both of them. Microsoft, at one point, attempted and failed to head this off by adding an extra http transport to DCE/RPC called ncacn_http (Network Computing Architecture connection-oriented protocol). This was later resurrected to support a Microsoft Exchange 2003 connection over HTTP.

DCOM is supported natively in Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, as well as Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016.

Dynamic-link library

Dynamic-link library (or DLL) is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems. These libraries usually have the file extension DLL, OCX (for libraries containing ActiveX controls), or DRV (for legacy system drivers).

The file formats for DLLs are the same as for Windows EXE files – that is, Portable Executable (PE) for 32-bit and 64-bit Windows, and New Executable (NE) for 16-bit Windows. As with EXEs, DLLs can contain code, data, and resources, in any combination.

Data files with the same file format as a DLL, but with different file extensions and possibly containing only resource sections, can be called resource DLLs. Examples of such DLLs include icon libraries, sometimes having the extension ICL, and font files, having the extensions FON and FOT.


In computer programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM). The COM specification mandates that COM objects must implement this interface. Furthermore, every other COM interface must be derived from IUnknown. IUnknown exposes two essential features of all COM objects: object lifetime management through reference counting, and access to object functionality through other interfaces.

An IUnknown (or IUnknown-derived) 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 order that they are declared in the interface. The in-process invocation call overhead is therefore identical to virtual method calls in C++.

Microsoft Transaction Server

Microsoft Transaction Server (MTS) was software that provided services to Component Object Model (COM) software components, to make it easier to create large distributed applications. The major services provided by MTS were automated transaction management, instance management (or just-in-time activation) and role-based security. MTS is considered to be the first major software to implement aspect-oriented programming.MTS was first offered in the Windows NT 4.0 Option Pack. In Windows 2000, MTS was enhanced and better integrated with the operating system and COM, and was renamed COM+. COM+ added object pooling, loosely-coupled events and user-defined simple transactions (compensating resource managers) to the features of MTS.

COM+ is still provided with Windows Server 2003 and Windows Server 2008, and the Microsoft .NET Framework provides a wrapper for COM+ in the EnterpriseServices namespace. The Windows Communication Foundation (WCF) provides a way of calling COM+ applications with web services. However, COM+ is based on COM, and Microsoft's strategic software architecture is now web services and .NET, not COM. There are pure .NET-based alternatives for many of the features provided by COM+, and in the long term it is likely COM+ will be phased out.

OLE Automation

In Microsoft Windows applications programming, OLE Automation (later renamed to simply Automation) is an inter-process communication mechanism created by Microsoft. It is based on a subset of Component Object Model (COM) that was intended for use by scripting languages – originally Visual Basic – but now is used by several languages on Windows. All automation objects are required to implement the IDispatch interface. It provides an infrastructure whereby applications called automation controllers can access and manipulate (i.e. set properties of or call methods on) shared automation objects that are exported by other applications. It supersedes Dynamic Data Exchange (DDE), an older mechanism for applications to control one another. As with DDE, in OLE Automation the automation controller is the "client" and the application exporting the automation objects is the "server".

Contrary to its name, automation objects do not necessarily use Microsoft OLE, although some of Automation objects can be used in OLE environments. The confusion has its roots in Microsoft's earlier definition of OLE, which was previously more or less a synonym of COM.


OLE DB (Object Linking and Embedding, Database, sometimes written as OLEDB or OLE-DB), an API designed by Microsoft, allows accessing data from a variety of sources in a uniform manner. The API provides a set of interfaces implemented using the Component Object Model (COM); it is otherwise unrelated to OLE. Microsoft originally intended OLE DB as a higher-level replacement for, and successor to, ODBC, extending its feature set to support a wider variety of non-relational databases, such as object databases and spreadsheets that do not necessarily implement SQL.


RIFE is a content management framework designed for rapid web application development in Java, without using J2EE.

RIFE's design blends together in a consistent component object model two approaches, request-based and component-based. Through a centralized site structure (web engine), an application can be split up into reusable binary modules that can be integrated into other projects.

Visual Basic

Visual Basic is a third-generation event-driven programming language from Microsoft for its Component Object Model (COM) programming model first released in 1991 and declared legacy during 2008. Microsoft intended Visual Basic to be relatively easy to learn and use. Visual Basic was derived from BASIC and enables the rapid application development (RAD) of graphical user interface (GUI) applications, access to databases using Data Access Objects, Remote Data Objects, or ActiveX Data Objects, and creation of ActiveX controls and objects.

A programmer can create an application using the components provided by the Visual Basic program itself. Over time the community of programmers developed third-party components. Programs written in Visual Basic can also use the Windows API, which requires external function declarations.

The final release was version 6 in 1998 (now known simply as Visual Basic). On April 8, 2008, Microsoft stopped supporting Visual Basic 6.0 IDE. The Microsoft Visual Basic team still maintains compatibility for Visual Basic 6.0 applications on Windows Vista, Windows Server 2008 including R2, Windows 7, Windows 8, Windows 8.1, Windows Server 2012, Windows 10, Windows Server 2016, and Windows Server 2019 through its "It Just Works" program. In 2014, some software developers still preferred Visual Basic 6.0 over its successor, Visual Basic .NET. In 2014 some developers lobbied for a new version of the VB6 programming environment. In 2016, Visual Basic 6.0 won the technical impact award at The 19th Annual D.I.C.E. Awards. A dialect of Visual Basic, Visual Basic for Applications (VBA), is used as a macro or scripting language within several Microsoft applications, including Microsoft Office.

WinWrap Basic

WinWrap Basic (WWB) by Polar Engineering, Inc. is a third-party macro language based on Visual Basic used with programmes of various types which its vendor touts as an alternative to ActiveX (e.g. VBScript, JScript, PerlScript, Rexx-based WSH engines and others), Visual Basic for Applications, and VSTA for this purpose. The WWB software package is used in conjunction with Microsoft development tools including Visual Studio, Visual Studio.NET, and the ActiveX scripting engines. The default file extension for programmes written in this language is .wwb

WWB 10 has Windows Scripting Host functionality, i.e. it contains a scripting engine similar to the default and third-party language implementations for WSH. This engine is able to access both the .NET framework and the Component Object Model.

The current version, 10.01, is available for different combinations of OS and platform. At this time there are four types of WWB, those being WWB.NET for the .NET object model (used with Visual Studio.NET 2005 and 2008 and Vista), .WWB-COM for the COM object model (Visual Studio and Visual Studio.NET earlier versions), both of which are used with all Windows 32 and 64-bit operating systems from Windows 95 to Windows Vista; the other two packages are for Windows CE and PocketPC & Windows Mobile. Earlier versions of WWB ran under Windows 3.1 and ostensibly OS/2 Warp 3 as well.

WWB is integrated into many software packages including most categories of PC and server software (e.g. earlier versions of Host Explorer, which now uses two proprietary scripting languages, Hummingbird QuickScript and Hummingbird Basic) as well as software used to run various types of equipment like mass spectrometers and other lab equipment.

Windows Imaging Component

Windows Imaging Component (WIC) is a Component Object Model based imaging codec framework introduced in Windows Vista (and later available in Windows XP Service Pack 3) for working with and processing digital images and image metadata. It allows applications supporting the framework to automatically get support of installed codecs for graphics file formats.

It is similar to DirectShow, or ACM/VCM, in that it can be extended using image codecs and can support third-party graphics formats on a system-wide basis. Additionally, Windows Presentation Foundation applications also automatically support the installed image codecs. Codecs for RAW image formats used by high-end professional digital cameras are also supported in this manner.

WIC enables application developers to perform image processing operations on any image format through a single set of common APIs, without requiring prior knowledge of specific image formats. By writing a codec once for WIC, developers can get system-wide support for that graphics file format in all applications that use WIC, .NET 3.x or WPF.


Cross Platform Component Object Model (XPCOM) is a cross-platform component model from Mozilla. It is similar to Microsoft Component Object Model (COM) and Common Object Request Broker Architecture (CORBA). It features multiple language bindings and interface description language (IDL) descriptions; thus programmers can plug their custom functions into the framework and connect it with other components.

The most prominent usage of XPCOM is within the Firefox web browser. Many of its internal components interact via XPCOM interfaces. Furthermore, Firefox used to allow add-ons extensive XPCOM access, but this was removed in Firefox 57 and replaced with the less-permissive WebExtensions API. (Three forks of Firefox still support the legacy add-on capability: Pale Moon, Basilisk, Waterfox.)

Data access
Administration and
Component model
Device drivers
Software factories
Text and multilingual
File systems
Spun off to
Microsoft Store

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.