Producing an EXE-based server is a little more straightforward than producing a DLL-based server because the Support MFC, Allow Merging Of Proxy/Stub Code, and the Support MTS options are turned off. EXE-based servers run in their own process space, have their own primary thread, and service the message queue. As with DLL-based servers, EXE servers perform the correct contortions to be COM servers.
Instead of exporting the well-known functions for exposing class objects, an EXE server exposes its class objects via the COM API function CoRegisterClassObject. Calls to these functions are hidden within ATL's CComModule class. Instead of exporting DllRegisterServer and DllUnregisterServer, ATL-based EXEs check the command line for /RegServer or /UnRegServer to install information in the Registry. Finally, rather than being unloaded passively (as DLLs are), an EXE server watches its reference count go up and down and unloads itself when the reference count drops to 0.
Selecting a COM-based EXE from the ATL COM AppWizard yields the following files:
Compiling the project yields three more files:
As with a DLL-based server, an EXE server generated by the AppWizard also includes IDL code. Compiling the EXE yields enough source code to create a proxy/stub DLL capable of remoting the interfaces described within the IDL file.