Simply put, BEGIN_COM_MAP implements _InternalQueryInterface. COM_INTERFACE_ENTRY indicates that your class supports the specified interface. END_COM_MAP finishes the _InternalQueryInterface implementation.

Note: A QueryInterface implementation which calls this _InternalQueryInterface method must either be hand-coded, or supplied by CComObject, CComAggObject, etc.

For example:

class MyClass :
    public CComObjectRoot,
    public ISomeInterface
{
public:
    BEGIN_COM_MAP(MyClass)
        COM_INTERFACE_ENTRY(ISomeInterface)
    END_COM_MAP()
};

CComClass myInstance = new CComClass;

The COM_INTERFACE_ENTRY line indicates that MyClass implements ISomeInterface. If QueryInterface is called to requests an ISomeInterface pointer, the call will succeed. Without the COM_INTERFACE_ENTRY line, the QueryInterface call would fail.

Many CAPICOM pages contain a confusing, bright-red header along the lines of:

[The SignedCode object is available for use in the operating systems listed in the Requirements section. Instead, use Platform Invocation Services (PInvoke) to call the Win32 API SignerSignEx, SignerTimeStampEx, and WinVerifyTrust functions to sign content with an Authenticode digital signature. For information about PInvoke, see Platform Invoke Tutorial. The .NET and CryptoAPI via P/Invoke: Part 1 and .NET and CryptoAPI via P/Invoke: Part 2 subsections of Extending .NET Cryptography with CAPICOM and P/Invoke may also be helpful.]

Note that this alarming paragraph seems to begin by simply telling you that this API is supported on the operating systems listed later. It does not state that the API will not be available on later OSes, but why place this here otherwise? The next sentence, beginning with, “Instead, …” seems to be contrasting with something, yet makes absolutely no sense in this context.

Finally, this paragraph instructs us to investigate SignerSignEx, and SignerTimeStampEx, which are supplied by the mssign32.dll, have no header file, and absolutely no example code. This is what I find most irksome, they document each and every function and structure, yet each page says, “there is no header file, so copy and paste the declaration given here.” Well, why not simply provide an mssign.h file on blogs.msdn, or similar? And why, oh why, is there not a single line of sample code?

Follow-up

I have provided a basic header file for mssign32.dll, here.

This was a mystery since regsvr32 appeared to properly register our DLL, and all the obvious registry keys were intact!

After a bit of web searching, I experimented with using CLSCTX_ALL instead of CLSCTX_INPROC_SERVER. Now, the call succeeded! But why, since this is a DLL and, therefore, should be considered an in-process COM server?

MSDN documentation states that CLSCTX_ALL is defined as the combination of CLSCTX_INPROC_SERVER, CLSCTX_INPROC_HANDLER, and CLSCTX_LOCAL_SERVER. I began substituting each one in turn and found that the key was CLSCTX_LOCAL_SERVER.

Stepping through the code in the debugger revealed that the instant the CoCreateInstance call was made, a new instance of dllhost.exe appeared in the process list. This explained why CLSCTX_INPROC_SERVER would fail, since strictly speaking, the DLL was being hosted in dllhost’s process space.

Ultimately, the problem turned out to be an artifact from an old COM+ experiment. There was a COM+ entry corresponding to our COM server in the Component Services panel (Control Panel | Administrative Tools | Component Services, under Component Services | Computers | My Computer | COM+ Applications). The COM+ entry dictated that the COM server be hosted by proxy by dllhost.exe. Deleting this COM+ entry and re-running regsvr32 fixed the problem.