3

I'm in the process of implementing my first out-of-process COM server (my first COM server altogether, for that matter). I have followed the steps to write an IDL file, generate the code for the proxy/stub DLL, compile the DLL, and register it.

When I check the registry keys, I have

  • A key named HKEY_CLASSES_ROOT/Interface/<GUID>, whose vaue is (say) IMyApp and
  • A key named HKEY_CLASSES_ROOT/Interface/<GUID>/ProxyStubClsid32, whose value is <GUID>, i.e. the same value as in the key name

I don't understand how the the second key's value can be the same <GUID> value as in the key name, because my current understanding is that

  • In HKEY_CLASSES_ROOT/Interface/<GUID>, GUID is an interface ID
  • The value of ProxyStubClsid32 is not an interface ID, but a class ID referring to the component that implements the above interface
  • The value of HKEY_CLASSES_ROOT/CLSID/<GUID>/InprocServer32 (where GUID is the above class ID) points to the proxy DLL

How, then, can the value of HKEY_CLASSES_ROOT/Interface/<GUID>/ProxyStubClsid32 hold the same value GUID if one is an interface ID and the other is a class ID?

EDIT: I'm still hoping for an answer to this one. To put it short: Since a component and an interface are two different things, how can the same ID be used for both?

Dabbler
  • 9,733
  • 5
  • 41
  • 64
  • Why don't you look for `ProxyStubClsid32` in registry to find existing COM class with this value in order to see the details of layout? Not to mention that [MSDN explains the layout](http://msdn.microsoft.com/en-us/library/windows/desktop/ms688573%28v=vs.85%29.aspx). – Roman R. Oct 19 '12 at 17:38
  • Because microsoft designed it that way. – Wug Oct 19 '12 at 17:39
  • @Roman R: The COM class is the server I am about to write, so it's not even registered yet – Dabbler Oct 19 '12 at 17:45
  • I mean you can use others as an example. – Roman R. Oct 19 '12 at 17:47
  • @Wug: Isn't the purpose of the [...]/Interface/ key to find the component for a given interface? When a component has several interfaces, they will have different IDs, but there is still just one component. So the question remains how the values can be the same. – Dabbler Oct 19 '12 at 17:49
  • I know a little bit about com interop, but I also know that you're not supposed to do anything with those registry settings yourself (doing so usually leads to broken registries). Microsoft provides tools to register and unregister classes, and the process by which classes are looked up and stored is poorly (if at all) documented. – Wug Oct 19 '12 at 17:58
  • I suspect you are confusing classes. There is certain class, with its `CLSID`. It implements interfaces, each of them has its own `IID`. Now an interface in its turn might have custom class for marhshaling purposes, with its own `CLSID` (because this custom class is also a COM class). And these two `CLSID`s are not equal, they are actually different classes, with dfiferent identifiers and purposes. – Roman R. Oct 19 '12 at 18:02

3 Answers3

9

Your basic understanding of the way Guids are used in COM is correct. Notable first is that an interface and a coclass having the same guid is not a problem. They live in different registry keys, HKCR\Interface vs HKCR\CLSID and it is always clear in COM whether you are looking up a IID or a CLSID.

Second is the IDL you wrote. Note that there's no place there to specify the CLSID of the proxy, only the IIDs supported by the proxy and stub can be declared there.

Next, you need a wild goose chase through the way that the proxy/stub is autogenerated. The core Windows SDK header is RpcProxy.h, open it in a text editor to have a look see. The macro soup is very heavy but it does have a few decent comments that describe what's going on. The important RPC helper function is NdrDllRegisterProxy(), it registers the proxy and is called when you use Regsvr32.exe. Its 3rd argument specifies the CLSID of the proxy. I'll let you do the reading and just quote the important bits in the .h file:

Compiler switches:

-DPROXY_CLSID=clsid
    Specifies a class ID to be used by the proxy DLL.

This one you specify with Project + Properties, C/C++, Preprocessor, Preprocessor Definitions setting. Note that your project will not specify it.

Chasing through the soup then lands you on this one:

// if the user specified an override for the class id, it is
// PROXY_CLSID at this point

#ifndef PROXY_CLSID
#define GET_DLL_CLSID   \
    ( aProxyFileList[0]->pStubVtblList[0] != 0 ? \
    aProxyFileList[0]->pStubVtblList[0]->header.piid : 0)
#else  //PROXY_CLSID
#define GET_DLL_CLSID   &PROXY_CLSID
#endif //PROXY_CLSID

In other words, if you didn't specify the CLSID yourself (you didn't) then it uses the first IID in the stub table.

And that makes the ProxyStubClsid32 guid the same as the IID of your first interface. Feature, not a bug.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • That was very instructive, thanks! It's interesting to note that although a GUID is "globally unique", what it refers to can still be ambiguous and depend on an external context (component or interface). The reason I failed to understand that was because I thought they were like URIs in XML namespaces (where a URI's alone value uniquely determines the namespace in question), but that's not the case. – Dabbler Oct 27 '12 at 16:26
  • On second thoughts... If the CLSID isn't in the IDL file, the proxy/stub DLL never knows about it, so how does it ever get registered? It needs to be registered, right? – Dabbler Oct 27 '12 at 16:33
  • Not sure how to better explain it then I already did. NdrDllRegisterProxy() consumes the CLSID, 3rd argument, and writes the registry keys. GET_DLL_CLSID provides it. – Hans Passant Oct 27 '12 at 16:36
0

A case of Beginner's Confusion (tm). The class registered by calling regsrv32 is not the one with my CLSID. It is one generated specifically for the proxy/stub DLL (the friendly name PSFactory also indicates this). So as Roman R. suspected, there are two classes where I thought there was only one. My own CLSID is registered by the EXE server when it's called with the /Embedding switch.

Dabbler
  • 9,733
  • 5
  • 41
  • 64
0

For what i know, all the proxy/stub mayhem is managed now by the MIDL (inheriting from IDispatch not IUnknown, which you probably already do because you have the ProxyStubClsid32 reg key).

The only thing needed is to register the server properly (just building it or doing /RegServer did not register it properly for us... and for many others), to do so just a call to LoadTypeLibEx is needed (after building the server or installing it).

So just create a small exe with this code and call it after building and on installation:

String^ l_TLB = l_Path + "\\MyServer.tlb";
IntPtr  l_TLBP = System::Runtime::InteropServices::Marshal::StringToBSTR(l_TLB);
ITypeLib *pTypeLib;
HRESULT hr = LoadTypeLibEx(static_cast<LPCOLESTR>(l_TLBP.ToPointer()), REGKIND_REGISTER, &pTypeLib);
if(SUCCEEDED(hr))
    pTypeLib->Release();
Dario Durà Armadans
  • 21
  • 5