CoInitializeEx function

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 and dynamic 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 Java Beans, 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, which was released in 1992. 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[edit]

Related technologies[edit]
COM was the major software development platform for Windows and, as such, influenced development of a number of supporting technologies.

COM+ and DCOM[edit]
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 (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[edit]
Main article: .NET Framework
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[edit]
Main article: 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.

组件对象模型（英语：Component Object Model，缩写COM）是微软的一套软件组件的二进制接口标准。这使得跨编程语言的进程间通信、动态对象创建成为可能。COM是多项微软技术与框架的基础，包括OLE、OLE自动化、ActiveX、COM+、DCOM、Windows shell、DirectX、Windows Runtime。

COM实质上是一种语言无关的对象实现方式，这使其可以在创建环境不同的场合、甚至跨计算机的分布环境下被复用。COM允许复用这些对象，而不必知道对象内部是如何实现，因为组件实现者必须提供良好定义的接口从而屏蔽实现细节。通过引用计数，组件对象自己负责动态创建与销毁，从而屏蔽了不同编程语言之间的内存分配语义差异。在COM接口之间的类型转换通过QueryInterface方法。
对于某些应用程序来说，COM已经部分被.NET框架取代。COM通过Windows Communication Foundation（WCF）支持Web Service。COM对象通过.NET COM Interop可以被所有.NET语言使用。网络化的DCOM使用二进制私有格式，而WCF鼓励使用基于XML的SOAP消息机制。COM非常类似其他软件组件接口技术，如CORBA与JavaBeans，它们各自有其优点与弱点。
与C++不同，COM提供了一个稳定的应用二进制接口（ABI），不随编译器版本而改变 。

COM是基于组件对象方式概念来设计的，在基础中，至少要让每个组件都可以支持二个功能：
查询组件中有哪些界面
让组件做自我生命管理，此概念的实践即为引用计数（Reference Counting）
这二个功能即为COM的根：IUnknown接口所提供的IUnknown::QueryInterface()，IUnknown::AddRef()及IUnknown::Release()三个方法的由来。所有的COM组件都要实现IUnknown，表示每个COM组件都有相同的能力。
只由COM派生实现出来的组件，称为纯COM组件。
但在Windows持续发展时，Visual Basic 4.0开始支持OCX，也就是OLE Custom Control，这让微软开始思考要如何让COM组件可以跨语言支持，在这样的要求下，必须要提供一个一致的接口，以及提供一组可以调用接口内方法的能力，由于纯COM组件只能够支持C/C++的直接访问，为了要达到跨语言的能力，在COM中必须要支持在外部调用内部方法的机能，这个机能造就了Invoke()方法，另外为了跨语言的支持，COM应该要提供简单的组件访问识别方式，这也就是会有GetIDsOfNames()的原因，将这些方法组合起来，定义出的必要接口，称为IDispatch接口，所有实现此接口的，都可以支持跨语言的支持。
微软将实现此接口的组件都称为自动化（Automation）组件。