Creating a COM object in ASM

 

Copyright © Dec 27, 2000 by Ernest Murphy ernie@surfree.com

For educational use only. All commercial use only by written license.

 

Revised December 27 for inclusion with MASM32

 

Sample code for this article is available at: .../COM/examples/MyCom

 

The Build DLL setting used for Quick Editor is at .../COM/BIN/BLDDLL.BAT

 

 

Abstract:

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

The COM (Component Object Model) is based on a non-specific implementation standard (neither platform nor language is specified), but real world constraints of real computers add practical considerations to this standard.

 

Here, a simple yet fully functional COM object in-process server for the WinTel platform will be created. It will be tested in a Visual Basic environment to assure it's compliance to the standard.

 

---------------------------------------------------------------------------------------------------------------------The programs discussed in here is designed be assembled with the MASM32 package. The Visual Basic client was written in VB6, which still sets its form version as 5. If one edits the VB5 version to VB4 it might work in earlier versions, but this has not been tested. It should also work in any VBA application, but again this has not been tested.

 

I will make no attempt to explain the basics of the Component Object Model nor the COM contract here. I'm going to assume you are familiar with both, and such details as the vtable, the vtable pointer and such. If you are not so familiar, I suggest you check the previous articles here, or the best source of explanation is Dale Rogerson's "Inside COM" (see bibliography).

 

Since COM objects must run not in some textbook but on real computers, they must follow certain implementation standards specific to that computer and operating system. For a WinTel in-process server, there already exists a well-defined standard to load a blob of code and unload it when no longer needed: the humble dynamic link library.

 

From one view, all an in-process COM server consists of is a .DLL with a set of 5 well defined exports. These are:

 

DllMain: This is the first routine in any dll. It is called when the library is loaded. It should check that the client (the calling app) wants an in-process server, and fail if not. (COM supports other instancing choices, but this app does not.)

 

DllRegisterServer: The registry holds data on every COM object installed on the system. This routine self-registers the component in the registry. It is how regsvr32.exe can register a component, regsvr32 just calls this export and displays the return value.

DllUnregisterServer: When no longer needed, a component should be able to unregister itself. Again, regsvr32.exe will call this export to clean out the registry.

 

DllCanUnloadNow: Global variables in the server keep track of any objects created, and also if a lock was placed on the server (explained in IClassFactory.LockServer). The client app will periodically call this export to check if the server is no longer needed and then unload it.

 

DllGetClassObject: Finally the magic COM export. This export takes 3 parameters, the GUID of the component to be created, the GUID of that component's interface to be created, and a pointer to the object thus created. If either the component or the interface requested are not supported, this routine fails.

 

The first 4 exports are straightforward. DllGetClassObject is the new strange thing, and needs further comment.

 

By now, one thing you should have noticed is that COM is about nothing if it isn't about indirection. That indirection gives the power to the methods. In practice, the object returned from DllGetClassObject is not the object we seek: it is a "class factory" object. A class factory object is one that knows how to instance (create) another class. This first lever of indirection allows the details of the object's creation to be specified. If it simply and directly returned a pointer to the object, then the object already exists, thus we cannot set and control any parameters in its constructor.

 

DllGetClassObject returns a IClassFactory interface. IClassFactory inherits from IUnknown (of course, every interface does), as has these two member functions:

 

HRESULT CreateInstance(