HKEY_CLASSES_ROOTTypeLib{A21A8C42-1266-11D4-A324-0040F6D487D9}1.0HELPDIR

(Default) "C:masm32COMMyCom"

One key value here is variable, that is the path and name of the server dll itself. On my system I placed it at "C:MASM32COMMYCOMMYCOM.DLL" This was detected when I registered the component, as one other function of DllRegisterServer is to discover where the dll itself is stored by invoking GetModuleFileName.

This is a lot of information for one little server. But all we need know to instance our server is pass the ID of {A21A8C43-1266-11D4-A324-0040F6D487D9} and a valid interface ID to CoCreateInstance. We need not know where it the component is, nor place it in a special directory. The CoCreate API's will trace through the registry settings, starting with the CLSID to discover all it needs to know to create the component. Once it has the component, it can load the type library from that to learn more if need be.

Fortunately for us, the last 5 registry entries are done for us via the RegisterTypeLib API. In DllRegisterServer we call a series of registry functions to set the first 5 keys and values, then invoke RegisterTypeLib. DllUnregisterServer just winds through this structure and deletes all the entries it made, then invokes UnRegisterTypeLib. When deleting keys, do take care NOT to delete the entire HKEY_CLASSES_ROOTCLSID tree, as you will completely mess up your system and partially uninstall every other activeX component on your system.

A type library itself is defined as a "dense black blob" of binary data. The sole property of its internal structure revealed by Microsoft is the first 4 bytes shall be the ASCII code for "MSFT." To learn what is inside, API methods must be employed. Again, this keeps the COM contract language neutral.

Implementing the Unknown

---------------------------------------------------------------------------------------------------------------------

MyCom is a very simple object, it only impliments two interfaces, IUnknown and IMyCom. Since these two interfaces overlap, the returned ppv pointer need not be cast to either interface, and our very simple object structure will suffice. If you continue on to the CoLib (Component Library), you will see a much more involved object structure is required if multiple, non-overlapping interfaces are supported.

Object lifetime is handled by the IUnknown interface. These three seemingly simple methods of AddRef, Release, and QueryInterface are quite powerful, and are used such that the functionality of each is never duplicated in another section.

This non duplication of function is perhaps the impetus in why IUnknown was named such. When DllGetClassObject is invoked, the object CLSID and a specific interface IID are passed in to define what needs to be created. Think for a second: we are in effect asking DllGetClassObject to perform a QueryInterface on the object before we create it. That is not what happens, since we do not want to duplicate functionality (i.e., two identical QueryInterface implementations, one in the QueryInterface itself, one in DllGetClassObject). If nothing else, we would not want to maintain two sections of code that should have similar output.

Instead, when DllGetClassObject is invoked, we simply create the object defined by the CLSID. In effect, we create an unknown object. What is unknown is: Can this object support the interface we require?

That question is easily answered. DllGetClassObject will invoke QueryInterface on the unknown object. If it truly supports the interface, this reference is returned. If it does not support it, the object is deleted, and the DllGetClassObject returns a fail code.

AddRef is quite simple to implement. Since we have a simple object structure, and "this" is the base address of this structure, we can directly access all members of the object.