About the Component Object Model

Component Object Model (COM) is the latest in a series of software standards developed by Microsoft. The COM specification explicitly defines how binary software components may interact with one another. COM also defines the format of compiled machine code, irrespective of the programming language used to create a COM component.

Since COM is a binary standard, it removes compatibility barriers normally associated with the development of reusable software components-at least for Windows users. For example, a Delphi programmer can use COM components that were developed by Java, C++, or VB programmers. Any of these languages can create COM components that are compatible with the others.

Component software has traditionally been targeted at specific programming languages. C++ programmers created VBX controls for Visual Basic programmers; Delphi programmers bought VCLs. However, the rationale behind component software has always been the same: to extend the functionality of software, without writing a lot of code, by plugging-in small elements of software.

In fact, component software has become mainstream, while object-oriented programming has not. COM provides the best features of both. COM implements object-oriented principles by encapsulating object-oriented, reusable components as binary entities, rather than as source code stored in language-specific class libraries. COM does this in a way that permits developers to update COM components, without breaking the applications that use them.

What is a COM object?

In the world of COM, an object is an instance of software that contains the functions (called methods) that represent what the object can do (its intelligence) and associated state information (called properties) for those functions. An object is a data structure and functions that manipulate the structure.

COM interfaces

In COM, the only way to manipulate data associated with an object is through an interface to methods in the object. Since developers can add new functionality without breaking legacy applications, COM overcomes compatibility issues traditionally associated with DLLs.

When a COM component is updated to add additional or improved functionality, a new interface is defined that provides access to new methods (functions) in the object. Programs written for the original interface continue to work, since the updated COM component still supports the original, unchanged set of interfaces and methods as it did before, in addition to its new interfaces and methods.

Once the public interface is defined, it can't be changed later. Instead, COM component developers define a new interface that provides access to methods in the component. Since each set of methods belong to one interface, dramatic changes can be made between releases of COM components without incurring compatibility problems.

COM objects have Methods and Properties

When a COM component is loaded into memory, its functions are mapped to internal memory addresses. A COM interface is simply a pointer to a location in memory where a set of functions is stored. Functions are called methods by COM programmers. Methods perform some sort of action on an object. For example, the publish method of a handler object publishes a handler under control of the Designer COM API. Many COM objects support properties. A property is an item of data associated with an object. For example, a handler object has a Name property.

By convention, COM interface names begin with the letter I, which stands for interface. All COM objects implement an interface named IUnknown, which exposes three functions:

• AddRef. The AddRef function increments an internal counter each time the object is referenced.

• Release. The Release function decrements an internal counter each time that an object is released. When the internal reference counter becomes zero, Windows deletes the object.

• QueryInterface. The QueryInterface function queries a COM object to find out if it supports a particular interface. If it does, QueryInterface provides a pointer to the set of functions exposed by the interface.

It is unlikely that you will ever need to use IUnknown to query a CIC-related COM component, since our interfaces, methods, and properties are fully documented. However, each CIC COM component supports the standard IUnknown interface and its methods. The IUnknown interface is not described in any API documentation, since IUnknown is defined by the COM specification and is always available.

COM clients and servers

As with DDE, there are COM clients and COM servers. However, in the world of COM, these terms have new meaning.

• A COM server interacts with clients by implementing interfaces that direct the client to methods supported by the interface. In-process COM servers are DLLs that run on the local machine. Out-of-process COM servers are .EXE files that can reside on the local machine, or on a networked computer. The COM specification has been extended to provide support for distributed processes (DCOM) running on remote computers. The term COM is now synonymous with both COM and DCOM.

• A COM client is a program or object that calls methods in one or more interfaces provided by a COM server.

COM is a refinement of the thinking behind OLE, DDE, and ActiveX. COM makes it possible to create truly reusable software components that are compatible across programming languages. COM provides some relief from version conflicts associated with software updates, and creates a platform for truly distributed network computing.