Component Object Model

The Component Object Model [ kəmˈpoʊnənt ˈɒbdʒɪkt ˈmɒdl ] (abbreviated COM ) is a technology developed by Microsoft for interprocess communication under Windows . COM components can be implemented both in the form of runtime modules (DLLs) and as executable programs. COM is intended to make it possible to easily reuse program code that has already been written, in some cases across operating system boundaries. COM components can be used regardless of the programming language.

The Component Object Model was introduced by Microsoft in 1992 with the Windows 3.1 graphical user interface .

architecture

COM is based on the client-server model . A COM client creates a COM component in a so-called COM server and uses the functionality of the object via COM interfaces. Access to objects is synchronized within a process by so-called COM apartments.

COM server

A COM server is a runtime module ( dynamic link library ) or an executable program that was created in a COM-supporting programming language and that offers and can create COM components. There are three types of COM servers:

In-process server

In the case of the in-process server , the COM component is implemented in a DLL (they often have the file extension OCX under Windows ). These DLLs have the functions DllGetClassObject(), DllCanUnloadNow(), DllRegisterServer()and DllUnregisterServer()export. If a COM component of an in-process server is created, the associated server (a server can offer several COM components) is loaded into the client's process . In-process servers are particularly fast because the functions of the COM components can be accessed directly. The disadvantage is that in this way each process occupies its own memory space with the COM components used and no shared memory usage is possible.

Local server

Local servers are Windows executable programs that implement COM components. This program is started when a COM component is created (if it is not already running) - this means that an executable program must be available, a DLL cannot be called here. A simplified RPC protocol ( Remote Procedure Call ) is used for communication between client and server . Local servers have the advantage that they only have to be started once and can then serve many clients, which takes up less storage space. In addition, data access to a common database can be carried out synchronized by several running clients (such as in Microsoft Outlook ). However, access via RPC is slower.

Remote server

If the server and client are in a computer network , DCOM ( Distributed COM ) is used. The use of DCOM basically enables the server and client to be operated on different operating systems.

In contrast to the local server, DCOM uses a fully implemented RPC, which, however, significantly slows down the calls (even with very little network load). The implementation of DCOM also differs from that of COM with local server in the upstream protocol stack .

COM interface

The COM interface is used for communication between client and server. For this purpose, a COM component can be addressed via generally defined and specified interfaces (e.g. IUnknown, IDispatch) as well as via special interfaces.

Each interface has a globally unique identification number, the GUID ( Globally Unique Identifier ). This means that several interfaces can exist with the same name (but not with the same GUID).

To enable a programming language across client / server communication, the so-called place at the interface marshaling instead, which converts the data to be exchanged in a predefined binary representation.

An interface fulfills the function of an abstract class that only contains virtual member functions, which (due to the separation of declaration and implementation) are all set to 0 in the vtable . The C version of an interface is accordingly a structure that contains function pointers . The COM objects created are used via pointers to their interfaces.

When a COM object implements an interface, it must overwrite all methods of the interface, i.e. fill the vtable. At least the three methods are IUnknownto be implemented that are responsible for the life cycle management and reveal any other implemented interfaces.

In the IDL ( Interface Definition Language ) that can be used for COM components, an interface looks like this (the interface serves as an example IUnknown):

// Standardschnittstelle aller COM-Komponenten
[
    object,
    uuid(00000000-0000-0000-C000-000000000046)
]
interface IUnknown {
    [restricted]
    HRESULT _stdcall QueryInterface([in] GUID* rrid, [out] void** ppvObj);
    [restricted]
    unsigned long _stdcall AddRef();
    [restricted]
    unsigned long _stdcall Release();
}

Each interface must IUnknowndefine the functions of the interface shown here via an interface inheritance , since this implements the basic functions for COM. A further inheritance of the interface definitions is possible.

Since programming languages such as Visual Basic Script do not know any types, Microsoft has developed another way of calling functions from COM interfaces. For this option, the interface must IDispatchdefine the functions of the interface . This makes it possible to IDispatch.Invoke()address a COM component via without the COM client having to know the type library of the server. Since access via the dispatch interface is much slower than access via a typed interface, both are often implemented ( dual interface ), so that programming languages that can handle pointers have both access options.

COM component

A COM component offers the functions that can be called via one or more COM interfaces. The object is created by implementing IClassFactory.CreateInstance()in the COM server.

The service life of an object is controlled by means of reference counting . A COM component only lives as long as the difference between the calls AddRef()(at the beginning of the use of an instance) and Release()(released after the use of the instance) is not 0.

A COM component can offer several interfaces. This is also necessary in certain situations in order to be able to expand a program without having to recompile other programs, because the compiler encodes the entry addresses read from the vtable for the functions called by the client under certain circumstances. If the interface of a component is changed later, the entry address can change, which would impair the functionality of the client. To expand the server functionality, another interface is implemented instead.

Inheritance of COM components ( aggregation ) is only possible in a few programming languages due to the requirements of binary compatibility. For this purpose, the component to be inherited is published by explicitly routing the interfaces through the inheriting component.

COM client

The client is the program that

possibly an object of a COM component generated via a COM server and
uses the functions offered by the COM component.

The client knows the functions that are offered by the COM component, as these are declared in the corresponding COM interfaces. The publication of interfaces takes place either via type libraries or descriptions in the IDL ( Interface Definition Language ).

Apartments

COM objects are always assigned to a so-called apartment when they are created. These are transparent frames that are used to synchronize method calls from multiple objects that have different thread safety requirements . If COM is not informed that a corresponding component is thread-safe, COM will only allow one call to an object at a time. Thread-safe components can execute any number of calls simultaneously on any object.

If a call is made in the same apartment between different objects, no marshaling is required. However, if an interface is used across apartment boundaries, marshaling must take place.

Each thread that wants to use COM must assign itself to an apartment (MTA) or create a new apartment (STA) before using a COM functionality for the first time. This is done using the function CoInitialize(). Programming languages with integrated COM support (for example VB6 and most .NET languages) often carry out this assignment automatically.

Each COM component is assigned to an apartment when it is created. If the apartment requirements of the generated component match the apartment of the generating thread, the object is assigned to the same apartment. When accessing beyond process limits, the two objects are always in different apartments. The assignment to an apartment cannot be changed during the life of the property.

There are three types of apartments:

Single Threaded Apartments (STA) have exactly one thread and any number of objects. Any number of STAs can exist in a process. There is only one call to the object to be called at a time. The remaining calls wait in a queue for the apartment thread to be released. This implies that two objects in the same STA cannot be called in parallel by two different clients. As a special feature, the first STA initialized in a process automatically becomes the main STA. There is only one main STA per process; all objects that do not make any explicit demands on the apartment are created in it.
Multi Threaded Apartments (MTA) have any number of threads. However, there is a maximum of one MTA in a process. As a result, calls to the same or different objects can be made simultaneously from several clients. The requirements for the implementation of the components are very high due to the necessary thread safety and reentrancy.
Neutral Threaded Apartments (NTA) have no thread affinity. However, there is a maximum of one NTA in a process. Any object in an NTA can be called from an STA / MTA apartment without thread transition. The thread is therefore briefly loaned to the NTA in order to skip the marshaling for performance reasons. Neutral Threaded Apartments was introduced with Windows 2000 in order to combine the advantages of MTA (mostly no marshaling necessary) with the advantages of STA (no thread-safe implementation necessary).

Functionality

There are possibilities through the use of COM

language independent,
version-independent,
platform independent,
object-oriented,
location-independent,
automating

to program. Many of the functions of the "Windows Platform SDK " are accessible via COM. COM is the basis on which OLE automation and ActiveX are built. With the introduction of the .NET framework, Microsoft pursued the strategy of replacing COM under Windows with this framework. The individual points of the list are explained in more detail below.

Language independence

COM components are independent of the programming language. COM supports the so-called binary standard . The generated binary file provides the implemented functions on the one hand and an interface that shows these functions on the other . With the help of the interface it is possible to use the functions from other programs. We work with concepts from the area of distributed systems .

Version independence

Another advantage of using COM is that you can easily integrate the management of new software features into an existing application. Problems can often arise if manufacturer-neutral or cross-manufacturer software components are equipped with additional functions. This allows your own software to be expanded, but there is a risk that other software that also uses the manufacturer-independent components will no longer function properly.

COM offers a robust way of expanding a software component with new functions. This is made possible by the fact that several interfaces can be combined in a header file . The following C ++ program code illustrates this:

//
// Interface mathematik.h
//
class IStandardMathFunctions : public IUnknown
{
public:
    STDMETHOD(Addieren)(long, long, long*)
    STDMETHOD(Subtrahieren)(long, long, long*)
};

class IAdvancedMathFunctions : public IUnknown
{
public:
    STDMETHOD(Fibonacci)(short, long*)
}

This header file called mathematik.hincludes two interfaces. The first interface could, for example, offer the manufacturer-independent functions that are used by different programs. IAdvancedMathFunctionsThis software component is expanded by the second interface . Further interfaces can be added at any time. The old interfaces and the functions they contain are not lost. Adding new interfaces instead of changing them is the way Microsoft intends to expand software components, since this does not result in inconsistencies.

Platform independence

Thanks to marshaling, x64 applications can access 32-bit COM servers (and vice versa). The COM server must then run in its own process and its objects cannot be instantiated as an in-process server. COM applications, however, are almost exclusively dependent on the Windows operating system family and the hardware supported by it; platform independence was designed, but was only implemented in a few exceptional cases.

Object orientation

When using COM, the work is object-oriented . Nevertheless, COM components can also be created and used in C, for example, since the interfaces are actually a collection of function pointers ( abstract class in C ++ , struct in C ).

Location independence

COM is location-independent , i. This means that the individual COM components are registered at a central point ( registration database ) , so that the components can be accessed regardless of their actual location.

automation

Controlling applications via COM interfaces is known as automation. This application option is often used in the context of OLE ( Object Linking and Embedding ).

safety

A vulnerability in the RPC implementation of DCOM made it possible to attack the well-known W32.Blaster worm .

literature

Peter Loos: Go to COM. The object model viewed in detail . 1st edition. Addison-Wesley, 2000, ISBN 978-3-8273-1678-3
Olaf Zwintzscher: An overview of software components. Introduction, classification & comparison of JavaBeans, EJB, COM +, .Net, CORBA, UML 2. W3L, Herdecke 2005, ISBN 3-937137-60-2

Web links

Component Object Model (COM) Microsoft

Individual evidence

↑ Com_Interface_Entry Macros (Atl) . MSDN
↑ Understanding COM Apartments, Part I (CodeGuru)
^ Christian Gross: Building COM Components on UNIX. Microsoft, July 1998, accessed May 29, 2016 .
↑ Kersten Auel: DCOM for Unix: now from the Open Group. Heise Medien, March 8, 1999, accessed May 29, 2016 .

[1] Com_Interface_Entry Macros (Atl) . MSDN

[2] Understanding COM Apartments, Part I (CodeGuru)

[3] Christian Gross: Building COM Components on UNIX. Microsoft, July 1998, accessed May 29, 2016 .

[4] Kersten Auel: DCOM for Unix: now from the Open Group. Heise Medien, March 8, 1999, accessed May 29, 2016 .