What's the difference between calling CComModule.RegisterServer, _AtlComModule.RegisterServer, and LoadTypeLibEx for TypeLib registration?

Question

In my DllRegisterServer method of my COM dll, I previously had code that called LoadTypeLibEx(module, REGKIND_REGISTER, &pTypeLib) to register my COM classes and their corresponding TypeLib's. My COM DLL is a 64-bit. I've noticed that on my 64-bit Vista system, under HKCR:\\TypeLib\{myguid}\1.0\0 I find a win32 subkey with the location to my COM DLL.

I also have some other code in a seperate COM DLL that I support that uses the older, now deprecated CComModule.RegisterServer(TRUE) call. This code creates a win64 subkey under the 0 key for a 64-bit DLL and a win32 subkey under the 0 key for a 32-bit DLL. I am using the correct bit version of regsvr32 to do the registration in all cases (matching the regsvr32 bitness to DLL bitness).

Why does LoadTypeLibEx and _AtlComModule.RegisterServer both not create the win64 key for a 64-bit dll containing my TypeLib while the older CComModule.RegisterServer creates the correct keys?

Answer 1

It appears that perhaps the behavior I'm seeing regarding win32/win64 subkeys reflects the fact that some type libraries can be used in 64-bit and 32-bit programs because there they contain no bit-constrained (read: pointer) parameters. Other type libraries, meanwhile, need different entries for win32 and win64 because they are not compatible.

Thus, it would seem that the behavior I'm seeing isn't really because of the registration methods I'm using, but because of the underlying type libraries.