Re: COM dll server registration on Windows 64 bits
"Olivier" <toon@toonworld.com> wrote in message
news:%236ybRxdfIHA.5208@TK2MSFTNGP04.phx.gbl...
Hello Willy,
Hello Willy,
Thank you very much for your tests.
Indeed, your results are very interesting because, using Windows XP 64
bits and VisualC++2005, there is no win64 sub key for the typelib
registration (only win32).
Indeed, I ran the same test on XP64, and effectively the sub key does not
get created by regsvr32, which is quite normal as COM itself doesn't know
about this subkey.
So, this seems different when using VS2008. I almost sure that Vista
does not play any role here. You should obtain same results as on
Vista64 when using VS2008 on WinXP64
No at all, VS2008 has nothing to do with this, actually I don't even use
VS2008 for this, I register the component using regsvr32.exe from the
command line and it's regsvr32 which add this subkey.
The version of regsvr32 on Vista-64 (SP1) and WS2008 differs from the
W2K3 and XP version, so does COM itself (ole32.dll).
Sorry, I have misread your previous post (I read "VS2008 = Visual Studio
2008" instead of "WS2008 = Windows Server 2008")
Nevertheless, the win64 subkey comes from somewhere. In our COM server
(i.e. in the DllRegisterServer() function) we use the ATL infrastructure
to register our coclasses (via the ATL Registrar Component + .rgs files)
and the associated typelib (_Module.RegisterServer( TRUE )).
So maybe the difference is inside the ATL library?
No, it's not, ATL has nothing to do with this , whatever method you use,
you'll end in calling "RegistryTypeLib" and/or "RegistryTypeLibForUser"
API's from oleaut32.dll.
You can trace this by means of the procmon tool (see
http://technet.microsoft.com/en-us/sysinternals/default.aspx), you can also
attach a debugger and set a breakpoint on oleaut32!RegisterTypeLib and step
through this function while watching the procmon output.
I can confirm that, on Vista and higher, oleaut32.dll is "bit-ness aware",
that is, the 64-bit version of oleaut32.dll (under system32) writes it's
typelib info under "win64" while the 32-bit version (under Syswow64) writes
it under "win32".
Willy.