System and Application Softwares
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)
cout << "Opening sun roof" << endl;
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?" .
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.
COM DLL Function Export
Meaning in Life
This method, which is technically optional, is used to install the necessary entries into the system registry.
This method (also technically optional) removes any and all entries inserted by DllRegisterServer().
This method is called by the COM runtime to determine if the DLL can be unloaded from memory at the current time.
This method is used to retrieve a given IClassFactory interface to the COM client based on the CLSID of the COM class in question. Once this interface has been obtained, the client is able to create the associated coclass.
Microsoft Interface Definition Language is the metalanguage used to describe COM types in language-independent format. Once you have created an *.idl file describing the COM types in a given COM server, the resulting *.idl file is sent into the Microsoft IDL compiler: midl.exe. The midl.exe compiler emits a binary equivalent termed a type library. This library contains the same information as the raw IDL, tokenized into a language-neutral format. By convention, type libraries end with the *.tlb file extension. This file, however, may be bundled into the COM server itself to keep the binary image more modular.
In addition to the *.tlb file, the MIDL compiler also generates a number of files that are intended to be used during the development of the COM server and C++ COM clients. The following figure illustrates the complete MIDL output.
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.
© 2020 Digcode.com. All rights reserved.