Object maps

The CComModule is connected to our COM object (CBeepObj) by the object map seen in the previous section. An object map defines an array

of all of the COM objects the server controls. The object map is defined in code using the OBJECT_MAP macros. Here is our DLL's object map:

BEGIN_OBJECT_MAP(ObjectMap)

OBJECT_ENTRY(CLSID_BeepObj, CBeepObj)

END_OBJECT_MAP()

The OBJECT_ENTRY macro associates the CLSID of the object with a C++ class. It is common for a server to contain more than one COM

object. When this is the case, there will be an OBJECT_ENTRY for each one.

Export File

Our In-Process DLL, like most DLLs, has an export file. The export file will be used by the client to connect to the exported functions in our

DLL. These definitions are in the file BeepServer.def:

; BeepServer.def : Declares the module parameters.

LIBRARY "BeepServer.DLL"

EXPORTS

DllCanUnloadNow @1 PRIVATE

DllGetClassObject @2 PRIVATE

DllRegisterServer @3 PRIVATE

DllUnregisterServer @4 PRIVATE

It is important to note what is not exported. There are no custom methods, and no export for the "Beep" method. The above are the only

exports you should see in a COM DLL.

Looking into the BeepServer.CPP file, we see that the implementation of these four functions is handled by the COM application class. Here's

the code for DllRegisterServer:

http://devcentral.iticentral.com/articles/DCOM/intro_DCOM/part2/3.php (2 of 6) [7/9/2001 2:52:53 PM]

DevCentral - Understanding DCOM - Part II

// DllRegisterServer - Adds entries to the system registry

STDAPI DllRegisterServer(void)

{

// registers object, typelib and all interfaces in typelib

return _Module.RegisterServer(TRUE);

}

In this case, the DLL just calls ATL's CComModule::RegisterServer() method. CComModule implements the server registration in a way that is

compatible with In-Process, Local, and Remote COM servers. The other four exported DLL functions are equally spartan. The actual

implementation is hidden in the ATL templates.

Most of the code described above is DLL-specific code. You will only get this configuration if you choose to create a DLL-based server. None of

the code in the main module is COM specific. The main module is entirely devoted to the infrastructure required to deliver COM objects in a

DLL, and this code will vary significantly depending on the type of server. The actual code inside the server is much more uniform. The

implementation of a coclass and interface is identical regardless of the type of server (DLL, EXE, server) you create. You can take a coclass

from a DLL server and implement it in an EXE-based server with few changes.

The COM Object -- "CBeepObj"

A COM server has to implement at least one COM object. We are using a single object named "CBeepObj." One of the most interesting things

about this object is that the code was entirely generated by ATL wizards. It is quite remarkable how compact this object definition turns out to

be. The class definition is found in BeepObj.h:

// BeepObj.h : Declaration of the CBeepObj

#include "resource.h" // main symbols

//////////////////////////////////////////////////////

// CBeepObj

class ATL_NO_VTABLE CBeepObj :

public CComObjectRootEx,

public CComCoClass,

public IBeepObj

{

public:

CBeepObj()

{

}

DECLARE_REGISTRY_RESOURCEID(IDR_BEEPOBJ)

BEGIN_COM_MAP(CBeepObj)

COM_INTERFACE_ENTRY(IBeepObj)

END_COM_MAP()

// IBeepObj

public:

STDMETHOD(Beep)(/*[in]*/ long lDuration);

};

This simple header file defines a tremendous amount of functionality, as described in the following sections.