View source for Component Object Model

{{Short description|Software component technology from Microsoft}}
{{Use mdy dates|date=January 2019}}
{{Use American English|date=January 2019}}
{{Infobox technology standard
| title             = COM
| long_name         = Component Object Model
| native_name       = 
| native_name_lang  = niasli

| image             = 
| caption           = 
| status            = In force
| year_started      = 
| version           = Living standard
| version_date      = 2021 
| preview           = 
| preview_date      = 
| organization      = [[Microsoft]]
| committee         = 
| related_standards = {{bulletedlist
|replaced: [[Dynamic Data Exchange|DDE]]
|built upon COM: [[Object Linking and Embedding|OLE]], [[OLE Automation]], [[Browser Helper Object]], [[ActiveX]], [[#COM+|COM+]], [[Distributed Component Object Model|DCOM]], [[Windows shell]], [[DirectX]], [[UMDF]], [[Windows Runtime]]}}
| abbreviation      = COM
| domain            = Component Interfacing
| license           =
| website           = {{URL|https://learn.microsoft.com/en-us/windows/win32/com/the-component-object-model}}
| first_published   = {{Start date and age|1993}}
| authors           =
| series            = [https://learn.microsoft.com/en-us/windows/win32/system-services System Services]
| editors           =
| base_standards    = [[Microsoft Interface Definition Language|MIDL]], [[Universally unique identifier|UUID]]
}}
'''Component Object Model''' ('''COM''') is a [[Application Binary Interface|binary-interface]] technology for [[software component]]s from [[Microsoft]] that enables using [[object (computer science)|objects]] in a [[language-neutral]] way between different [[programming languages]], programming contexts, [[Process (computing)|processes]] and [[computer|machines]].

COM is the basis for other Microsoft domain-specific component technologies including [[Object Linking and Embedding|OLE]], [[OLE Automation]], [[ActiveX]], [[#COM+|COM+]], and [[Distributed Component Object Model|DCOM]] as well as [[implementation]]s such as [[DirectX]], [[Windows shell]], [[User-Mode Driver Framework|UMDF]], [[Windows Runtime]], and [[Browser Helper Object]].

COM enables object use with only knowing its interface; not its internal implementation. The component implementer defines [[interface (object-oriented programming)|interface]]s 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|reference-counting]]. Access to an object's interfaces (similar to [[Type conversion]]) 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]] (API).<ref>{{cite web|url=https://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFPlugIns/Concepts/conceptual.html#//apple_ref/doc/uid/20001160-102910-BAJFDFFC|title=Documentation Archive|website=developer.apple.com}}</ref> The latter only implements a subset of the whole COM interface.<ref name="COM on MacOS">{{cite web | url = https://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFPlugIns/Concepts/com.html#//apple_ref/doc/uid/20001158-CJBEJBHH | title = Plug-ins and Microsoft's COM | publisher = [[Apple Inc.]] | access-date = 2010-10-05}}</ref> 

Over time, COM is being replaced with other technologies such as [[.NET Framework|Microsoft .NET]] and [[web services]] (i.e. via [[Windows communication foundation|WCF]]). However, COM objects can be used in a .NET language via [[COM Interop]]. 

COM is similar to other component technologies such as [[IBM System Object Model|SOM]], [[CORBA]] and [[Enterprise JavaBeans]], although each has its strengths and weaknesses. 

Unlike [[C++]], COM provides a stable [[application binary interface]] (ABI) that is unaffected by compiler differences.<ref>Microsoft forum: [https://archive.today/20130216110824/http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/86eda6a7-4d90-4e19-a9d4-6cbe22b661f4 Binary compatibility across Visual C++ versions]</ref> 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]] (DDE) was one of the first [[interprocess communication]] technologies in [[Windows]].<ref>{{cite web
   |title=About Network DDE - Windows applications  |website=[[Microsoft]].com
   |url=https://docs.microsoft.com/en-us/windows/desktop/ipc/about-network-dde
   |date=May 30, 2018}}</ref><ref>{{cite web   |website=[[McAfee]].com
   |title=Code Execution Technique Takes Advantage of Dynamic Data Exchange
   |url=https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/code-execution-technique-takes-advantage-of-dynamic-data-exchange
   |date=October 27, 2017}}</ref> It allowed sending and receiving messages in so-called ''conversations'' between applications. 

Antony 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]] (OLE), Microsoft's first object-based framework, was built on DDE and designed specifically for [[compound document]]s. It was introduced with [[Microsoft Word|Word]] and [[Microsoft Excel|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 (VBX) technology 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 [[property (programming)|properties]] and [[method (computer science)|methods]]. These were later adapted for use by other languages such as [[Visual C++]]. [[Windows 3.1x|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]] (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]]. 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]] (OCX) 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.<ref>Advanced Windows (The Developer's Guide to the Win32 API for Windows NT 3.5 and Windows 95)</ref>

In early 1996, Microsoft found a new use for OCX {{endash}} 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 [[Distributed Component Object Model|DCOM]].<ref>{{Cite journal|url=https://datatracker.ietf.org/doc/draft-brown-dcom-v1-spec/|title=draft-brown-dcom-v1-spec-03 - Distributed Component Object Model Protocol -- DCOM/1.0|newspaper=Ietf Datatracker|date=March 11, 1998|access-date=2019-08-29|last1=Brown|first1=Nina|last2=Kindel|first2=Charlie}}</ref>

==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===
{{Main article|Distributed Component Object Model}}

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 transaction]]s, 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 [[Distributed Component Object Model|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 {{endash}} 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 [[Microsoft Message Queuing|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===
{{Main|.NET Framework}}

'''.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 <code>System.EnterpriseServices</code> namespace, and several of the services that COM+ provides have been duplicated in .NET. For example, the <code>System.Transactions</code> namespace provides the <code>TransactionScope</code> class, which provides transaction management without resorting to COM+. Similarly, [[Queue (data structure)|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).<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/8bwh56xe.aspx|title=Runtime Callable Wrapper|last=rpetrusha|website=msdn.microsoft.com|date=April 19, 2023 }}</ref> NET objects that conform to certain interface restrictions may be used in COM objects by calling a ''COM callable wrapper'' (CCW).<ref>{{cite web|url=http://msdn.microsoft.com/f07c8z1c.aspx|title=COM Callable Wrapper|last=rpetrusha|website=msdn.microsoft.com|date=September 15, 2021 }}</ref> 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 [[Marshalling (computer science)|marshalled]] by value across process or machine boundaries more easily.

=== Windows Runtime ===
{{Main|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 [[metadata (CLI)|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 {{endash}} 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 {{endash}} identifies an interface type

* HRESULT {{endash}} method result codes such as S_OK, E_FAIL, E_OUTOFMEMORY

* IUnknown {{endash}} base type for object references; abstract virtual functions to support <code>dynamic_cast<T></code>-style acquisition of new interface types and ref counting a la <code>shared_ptr<T></code>

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

* <NanoCom>Alloc {{endash}} called by method implementations to allocate raw buffers (not objects) that are returned to the caller

* <NanoCom>Free {{endash}} 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++ <code>new</code> operator).

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

==Security==

===In Internet Explorer===

Since an ActiveX control (any COM component) runs as native code, with no [[Sandbox_(computer_security)|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".<ref>{{cite web |last1=Steinberg |first1=Jill |date=1997-03-01 |df=mdy |url=https://www.infoworld.com/article/2077623/competing-components-make-for-prickly-panelists.html |title=Competing components make for prickly panelists |work=[[JavaWorld]] |access-date=2020-07-16}}</ref> 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 [[code signing|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 (computer programming)|pointer]]'' in one subsystem can randomly corrupt other subsystems.

==Binding==

COM is supported via [[language binding|binding]]s in several languages, such as [[C (programming language)|C]], [[C++]], [[Visual Basic]], [[Delphi (programming language)|Delphi]], [[Python (programming language)|Python]]<ref>{{cite web|url=http://docs.activestate.com/activepython/2.4/pywin32/html/com/win32com/HTML/docindex.html|title=win32com Documentation Index|website=docs.activestate.com}}</ref><ref>{{cite web|url=http://www.boddie.org.uk/python/COM.html|title=Python and COM|website=www.boddie.org.uk}}</ref> and several of the Windows scripting contexts. Component access is via interface [[Method (computer science)|methods]]. This allows for direct calling in-process and via the COM/DCOM sub-system access between processes and computers.

==Type system==

===Coclass===

A '''coclass''', a COM class, implements one or more interfaces. It is identified by a class ID, called [[CLSID]] which is [[globally unique identifier|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 <code>[[IUnknown]]</code> interface, which exposes methods for [[reference counting]] and for accessing the other interfaces of the object {{endash}} 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 <code>[[IUnknown]]</code>, provides early bound access via a [[Pointer (computer programming)|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 <code>[[IDispatch]]</code>. 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 [[Microsoft Interface Definition Language|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 <code>struct</code> definitions to match the [[virtual method table|vtbl]]s of the declared interfaces and a C file containing declarations of the interface [[Globally Unique Identifier|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 call]]s 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 <code>SomeClass</code> which implements an interface named <code>ISomeInterface</code>.

<syntaxhighlight lang="idl">
coclass SomeClass {
  [default] interface ISomeInterface;
};
</syntaxhighlight>

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

<syntaxhighlight lang="cpp">
class ISomeInterface {};
class SomeClass : public ISomeInterface {
};
</syntaxhighlight>

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

<syntaxhighlight lang="cpp">
ISomeInterface* interface_ptr = NULL;
HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL, IID_ISomeInterface, (void**)&interface_ptr);
</syntaxhighlight>

==Reference counting==

A COM object uses [[reference counting]] to manage object lifetime. An object's reference count is controlled by the clients through the <code>IUnknown</code> <code>AddRef</code> and <code>Release</code> methods. COM objects are responsible for freeing their own memory when the reference count drops to zero. Some programming contexts (e.g. [[Visual Basic]]) provide automatic reference counting to simplify object use. In C++, a [[smart pointer]] can be used to automate reference count management.

The following are guidelines for when to ''AddRef'' and ''Release'' should called:

* A functions that returns an interface reference (via return value or via "out" parameter) increments the count of the returned object

* ''Release'' is called before the interface pointer is overwritten or goes out of scope

* If a copy is made on an interface reference pointer, ''AddRef'' is called

* ''AddRef'' and ''Release'' are called on the interface which is being referenced (not a different interface of the same object) since an object may implement per-interface reference counts in order to allocate internal resources only for the interfaces which are being referenced

For remote objects, not all reference count calls are sent over the wire. A a proxy keeps only one reference on the remote object and maintains its own local reference count. 

To simplify COM development for C++ developers, Microsoft introduced [[Active Template Library|ATL (Active Template Library)]]. ATL provides a relatively high-level COM development paradigm. It also shields COM client application developers from the need to directly maintain reference counting, by providing [[smart pointer]] types. Other libraries and languages that are COM-aware include the [[Microsoft Foundation Classes]], the [[Visual C++|VC]] Compiler COM Support,<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/h31ekh7e.aspx |title=Compiler COM Support|publisher=Microsoft|work=MSDN|date=August 3, 2021 }}</ref> [[VBScript]], [[Visual Basic 2005 Express Edition|Visual Basic]], [[ECMAScript]] ([[JavaScript]]) and [[Borland Delphi]].

==Programming context==

COM is a [[Language-independent specification|language agnostic]] binary standard that allows objects to be used in any programming context able to access its binary interfaces.  

COM client software is responsible for enabling the COM sub-system, instantiating and reference-counting COM objects and querying objects for supported interfaces. 

The Microsoft Visual C++ compiler supports extensions to the C++ language, referred to as ''C++ Attributes'', <ref>Microsoft MSDN: [http://msdn.microsoft.com/en-US/library/f520z3b3.aspx C++ Attributes Reference]</ref> that are designed to simplify COM development and minimize [[boilerplate code]] required to implement COM servers in C++.<ref>MSDN Magazine: [http://msdn.microsoft.com/en-us/magazine/cc301337.aspx C++ Attributes: Make COM Programming a Breeze with New Feature in Visual Studio .NET]</ref>

==Type metadata storage==

Originally, type library metadata was required to be stored in the system registry. A COM client would use the registry information for object creation.

Registration-free (RegFree) COM was introduced with [[Windows XP]] to allow storing type library metadata as an [[Manifest (CLI)|assembly manifest]] either as a resource in the executable file or in a separate file installed with the component.<ref name="msdndocs">{{cite web | url = http://msdn.microsoft.com/en-us/library/aa374219(VS.85).aspx | title = Assembly Manifests | publisher = [[MSDN]] | access-date = 2009-11-05}}</ref> This allows multiple versions of the same component to be installed on the same computer, in different directories. And it allows for [[XCOPY deployment]].<ref name="msdnmag">{{cite web | url = http://msdn.microsoft.com/en-us/magazine/cc188708.aspx | title = Simplify App Deployment with ClickOnce and Registration-Free COM | author = Dave Templin | publisher = [[MSDN]] Magazine | access-date = 2008-04-22}}</ref> This technology has limited support for EXE COM servers<ref>{{cite web | url = https://stackoverflow.com/questions/2369181/how-to-use-an-out-of-process-com-server-without-its-tlb-file | title = How to use an out-of-process COM server without its tlb file | access-date = 2011-04-16}}</ref> and cannot be used for system-wide components such as [[Microsoft Data Access Components|MDAC]], [[MSXML]], [[DirectX]] or [[Internet Explorer]].

During application loading, the Windows loader searches for the manifest.<ref name="isoconcept">{{cite web | url=https://msdn.microsoft.com/en-us/library/ms235531(v=vs.140).aspx | title = Concepts of Isolated Applications and Side-by-side Assemblies | publisher = [[MSDN]] | access-date = 2016-02-05}}</ref> If it is present, the loader adds information from it to the activation context.<ref name="msdnmag"/> 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 [[Windows Registry|registry]] is scanned.<ref name="msdnmag"/>

A COM object can be created without type library information; with only a path to the [[Dynamic-link library|DLL]] file and CLSID. A client can use the COM DLL function <code>DllGetClassObject</code> with the CLSID and IID_IClassFactory to create an instance of a [[Factory (object-oriented programming)|factory object]]. The client can then use the factory object's <code>CreateInstance</code> to create an instance.<ref>{{cite web|last1=Arkhipov|first1=Mikhail|title=Registration-free COM|url=https://blogs.msdn.microsoft.com/mikhailarkhipov/2005/04/01/registration-free-com/|website=MSDN Blogs|access-date=29 April 2016|date=1 April 2005}}</ref> This is the same process the COM sub-system uses.<ref>{{cite web|title=DllGetClassObject entry point (COM)|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680760%28v=vs.85%29.aspx|website=MSDN|quote=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.}}</ref> If an object created this way creates another object, it will do so in the usual way (using the registry or manifest). But it <!--what does it refer to?--> can create internal objects (which may not be registered at all), and hand out references to interfaces to them, using its own private knowledge.

==Marshalling==

A COM object can be transparently created and used 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 [[serialization|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.

==Threading==

In COM, threading is addressed through a concept known as ''apartments''.<ref>Microsoft MSDN: [http://msdn.microsoft.com/en-us/library/windows/desktop/ms693344.aspx Processes, Threads, and Apartments]</ref> 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 threading|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.

{| class="wikitable"
|-
! Apartment type!!Threading model!!Description
|-
| Single-Threaded Apartment<ref>Microsoft MSDN: [http://msdn.microsoft.com/en-us/library/windows/desktop/ms680112.aspx Single-Threaded Apartments]</ref> (STA)
||
Apartment
||
A single thread is dedicated to execute the methods of the object. Method calls from threads outside of the apartment are [[Marshalling (computer science)|marshalled]] and automatically queued by the system (via Windows messaging). Thus, the COM run-time provides synchronization to ensure that each method call to the object is executed to completion before another is invoked.
|-
| Multi-Threaded Apartment<ref>Microsoft MSDN: [http://msdn.microsoft.com/en-us/library/windows/desktop/ms693421.aspx Multithreaded Apartments]</ref> (MTA)
||
Free
||
The COM run-time provides no synchronization, and multiple threads are allowed to call object methods simultaneously. The object need to handle synchronization to prevent simultaneous access from multiple threads from problems. Calls to an MTA object from a thread in an STA are also marshalled.
|-
| Dynamically determined apartment
||
Both
||
The server auto-selects STA or MTA at object creation to match the apartment type of the calling thread.<ref>Microsoft MSDN: [http://msdn.microsoft.com/en-us/library/ms809971.aspx Understanding and Using COM Threading Models]</ref> This can be useful to avoid marshalling overhead when MTA servers are accessed by a STA thread.
|-
| Thread Neutral Apartment (NA)
||
Neutral
||
A special apartment without any assigned threads. When an STA or MTA thread calls an 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.<ref>Codeguru: [http://www.codeguru.com/cpp/com-tech/activex/apts/article.php/c5529/Understanding-COM-Apartments-Part-I.htm Understanding COM Apartments] {{Webarchive|url=https://web.archive.org/web/20210524175051/https://www.codeguru.com/cpp/com-tech/activex/apts/article.php/c5529/Understanding-COM-Apartments-Part-I.htm |date=May 24, 2021 }}</ref> 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.

==Criticisms==
{{Unreferenced section|date=January 2024}}

===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.<ref name="brumme-apartments">{{cite web |last=Brumme |first=Chris |title=Apartments and Pumping in the CLR |url=https://cbrumme.dev/apartments-and-pumping |access-date=2025-06-26 |publisher=Chris Brumme's Weblog}}</ref>

===Reference counting===
Reference counting within COM may cause problems if two or more objects are [[circular reference|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.<ref name="wolfe-circular">{{cite web |last=Wolfe |first=Mike |date=31 March 2022 |title=Reference Counting's Fatal Flaw: Circular References |url=https://nolongerset.com/circular-references/ |access-date=2025-06-26 |publisher=No Longer Set}}</ref>

===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==
* {{Annotated link|Calling convention}}
* {{Annotated link|Common Language Infrastructure}}
* {{Annotated link|D-Bus}}
* {{Annotated link|Foreign function interface}}
* {{Annotated link|Internet Communications Engine}}
* {{Annotated link|Java remote method invocation}}
* {{Annotated link|KDE Frameworks}}
* {{Annotated link|Name mangling}}
* {{Annotated link|Portable object (computing)}}
* {{Annotated link|SWIG}}

==Notes==
{{Reflist|2}}

==References==
*{{cite web |title=COM: A Brief Introduction (powerpoint) |url=http://alumni.cs.ucr.edu/~dberger/Documents/Presentations/com-intro.ppt |access-date=March 7, 2006 |type=Direct link to PowerPoint (PPT) file}}
*{{cite book | last=Box | first=Don | author-link=Don Box | title=Essential COM | publisher=Addison-Wesley | year=1998 | isbn=978-0-201-63446-4 | url=https://archive.org/details/essentialcom00boxd }}
*{{cite book | last = Chappell | first = David | title = Understanding ActiveX and OLE | publisher = Microsoft Press | year = 1996 | isbn = 978-1-57231-216-6 | url = https://archive.org/details/understandingact00chap }}
*{{cite web | title=Integration and Migration of COM+ services to WCF | url=http://msdn.microsoft.com/en-us/library/bb978523.aspx | access-date=April 15, 2010}}

==External links==
*[https://msdn.microsoft.com/en-us/library/windows/desktop/ms680573(v=vs.85).aspx Component Object Model on MSDN]
*[http://channel9.msdn.com/ShowPost.aspx?PostID=224935 Interview with Tony Williams, Co-Inventor of COM] (Video Webcast, August 2006)
*[http://support.microsoft.com/kb/159621/en-us Info: Difference Between OLE Controls and ActiveX Controls] from Microsoft
*[http://theircorp.byethost11.com/index.php?vw=TypeLib TypeLib Data Format Specification (unofficial)] with open source dumper utility.
*[https://web.archive.org/web/20090215185257/http://innovatia.com/software/papers/com.htm The COM / DCOM Glossary] (archive.org)

{{Microsoft APIs}}
{{Microsoft Windows components}}
{{Authority control}}

[[Category:Component-based software engineering]]
[[Category:Inter-process communication]]
[[Category:Microsoft application programming interfaces]]
[[Category:Object models]]
[[Category:Object request broker]]
[[Category:Object-oriented programming]]