Microsoft COM, OLE and Active Technologies

When C++ programmers build classes that support numerous interfaces, the simplest approach is to use standard multiple inheritance. Thus, you could update the HotRod definition as follows:

// The HotRod now supports two behaviors.
class HotRod: public ICar, IConvertible
{
    … same as before…

    // IConvertible impl.
    void LetTheSunIn(bool isOpening)
    {
        if(isOpening)
            cout << "Opening sun roof" << endl;
        else
            cout << "Closing sun roof" << endl;
    }
};

Of course, for the object user to make use of this new behavior, there must be a manner by which to query the type for a discrete interface (ICar or IConvertible). Ideally, the object itself would be able to return interface references to the user on request, rather than forcing the object user to perform awkward pointer casting directly. As you may already know, this is one of the core duties of the standard COM interface: IUnknown, it equips a COM type to return "yes" or "no" to the question "Do you support this interface?" .

The Composition of a COM DLL

All COM DLLs have the same internal composition regardless of which COM-aware language you build them in. The following figure illustrates the core atoms of the binary image of a COM DLL server:

A COM server contains some number of coclasses which is a type supporting at minimum the mandatory IUnknown interface. As shown in the above figure, the RawComServer.dll contains a single coclass named ComCar and it supports two interfaces: ICar and IUnknown.

COM servers also support a special sort of COM type termed a class factory (also termed a class object). COM class factories also support the mandatory IUnknown, as well as another standard interface named IClassFactory. This interface allows the COM client to create a given coclass in a language- and location-neutral manner. As you may be aware, it is possible for a COM class factory to support the IClassFactory2 interface (which derives from IClassFactory). The role of IClassFactory2 is to define additional methods to check for a valid license file before activating the object.

In addition to the set of coclasses and class factories, COM DLLs must support a small set of function exports. These function exports allow the COM runtime to interact with the internal types, as well as perform registration and unregistration of the COM binary itself. The following table provides a breakdown of each DLL export.

Type libraries can be standalone files with a .tlb extension, or they can be embedded in a file as a resource. They are typically contained in files with the extension .dll, .exe, .ocx, or .olb. A quick way to check for the presence of a type library in a file is to try opening the file in OLEVIEW.EXE.

Type libraries are often, but not always, registered in the Windows Registry (under HKEY_CLASSES_ROOT\TypeLib). Among other things, this enables programs such as Visual Studio .NET to present a user with a list of type libraries on the current computer.