COM dll server registration on Windows 64 bits
Olivier
(I apologize, if this is not the correct forum for my question, but I did
not find another one.)
Here is my question:
We have developed à COM dll server.
This latter is compiled in 32 bits AND 64 bits (without any changes). On
Windows 64 bits, the two versions may be ran at the same time by a 32 bits
and a 64 bits process client
I can't figure out if we need to change the CLSID of our COM objects for
each "bit model". I would prefer not changing them, otherwise that would
mean a lot of changes in our clients.
I tried to search these CLSID in the registry and found that they are
existing in both the 64 bits and 32 bits section (under Wow6432Node). I know
that Windows copies some registry keys from one section to the other, but
I'm not sure in which direction (maybe only when the server is 64 bits, and
so on...)
I wonder also if the registration order is important (i.e. do we need to
register the 64 bits version before or after le 32 bits one?). It seems that
it may change the way registration informations are stored in the registry.
Also, sometimes, we get the "Class is not registered" error. If we register
again our server, the error disappears.
So, what is the best practice to resolve this issue?
Any help in this area will be appreciated.
Best regards,
Olivier.
Olivier
The two dlls don't have the same name but are stored at the same location
For instance:
C:\Support\Server32.dll
C:\Support\Server64.dll
and the tlb are stored in both dlls.
Olivier.
"Olivier" <to...@toonworld.com> a écrit dans le message de news:
erzirY7d...@TK2MSFTNGP03.phx.gbl...
![Willy Denoyette [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXfXiAXGhHYcXf-iOUYGXHMIHmtAw4w01ItpjRcuAnrUu-vVQ=s40-c)
Willy Denoyette [MVP]
news:u5Vard7d...@TK2MSFTNGP03.phx.gbl...
All you need to take care of is that you register your COM server DLL's
using the right version of regsvr32.exe.
The 32-bit DLL must be registered with the 32-bit version of regsvr32
(%windir%\syswow64), while the 64-bit version must be registered with the
64-bit version (%windir%\sytem32).
Willy.
Ralph
They are two different hives - a 32-bit and a 64-bit. You must register them
as different using the respective versions of Regsvcs.exe. The order makes
no difference.
The "copying" you are seeing is actually the result of different 'views'.
That is, the 'hives' themselves don't actually exist as physical entities -
'hives' are the product of a query to the underlying registry store.
[Take a peek at the InprocServer32 key sometime.]
As they have different names storage is irrelevant. If you add additional
components to your stable, you might find it more convienent in the long run
(and helpful to your sanity <g>) to separate them into different folders
with different LibIDs, and manage similar code with conditional compiles.
But it really doesn't matter.
-ralph
Olivier
de news: %23FBzLnJ...@TK2MSFTNGP06.phx.gbl...
Hello Willy,
Thank you for your comment, but I'm not sure of this.
I tried to register the 32 bits version of our dll, using the regsvr32.exe
located in C:\Windows\System32, and it worked without any problem.
I tried also to regsister the 64 bits version, using the regsvr32.exe
located in C:\Windows\SysWow64, and it worked also without problem.
In fact, both versions of regsvr32 seems to work with both versions of our
dll.
I don't know how this works, but it works!
Here are informations about regsvr32.exe found on our 64 bits test machine:
C:\Windows\System32\RegSvr32.exe: 15 872 bytes, version 5.2.3790.1830
(srv03_sp1_rtm.050324-1447)
C:\Windows\SysWOW64\RegSvr32.exe: 12 800 bytes, version 5.2.3790.1830
(srv03_sp1_rtm.050324-1447)
Best regards,
Olivier.
Olivier
"Ralph" <nt_cons...@yahoo.com> a écrit dans le message de news:
eCbehnJe...@TK2MSFTNGP03.phx.gbl...
Hello Ralph,
> They are two different hives - a 32-bit and a 64-bit. You must register
> them
> as different using the respective versions of Regsvcs.exe.
It seems that it does not matter (see answer I made to Willy above in this
thread)
> The order makes no difference.
Humm... from our experience, it seems that this assertion is also false.
FYI, we use the ATL Registrar component to make registration (using .rgs
resources)
We have tried the following:
We have registered Server32.dll then Server64.dll and have searched for
Server32.dll and Server64.dll in the registry:
Server32.dll:
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
Server64.dll:
HKEY_CLASSES_ROOT\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
HKEY_CLASSES_ROOT\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
Registering in the reverse order, gives the following result:
Server32.dll:
HKEY_CLASSES_ROOT\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\TypeLib\{2FD8F657-77A0-11D5-BDD1-0050BAAE12A3}\1.0\0\win32
Server64.dll:
HKEY_CLASSES_ROOT\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{2FD8F665-77A0-11D5-BDD1-0050BAAE12A3}\InprocServer32
So the result differs.
I wonder also why there are
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node
and
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes ?
Best regards,
Olivier.
Olivier
We have another question related to this problem:
Can a 64 bits process (or dll) is able to access a TypeLib embedded in a 32
bits dll (or the opposite)?
Using ProcessExplorer, we saw a 64 bits dll listed in our 32 bits process
(and, yes, we are sure that this dll is 64 bits).
Best regards,
Olivier.
Willy Denoyette [MVP]
Don't know what you mean by "but it works!", do you mean you can register
whatever version of a dll with whatever version of regsvr32? Or do you mean
that it works at run-time?.
Anyways, you always need to use the 64-bit version of regsvr32 to register a
64-bit DLL, and the 32-bit version to register the 32-bit version. The same
applies to other tools like regedit.exe, there exists a 32-bit version and a
64-bit version, the 64-bit version gives you the "real view " of the
registry, while the 32-bit version gives you a "virtualized" view. Please
search MSDN for "Registry Virtualization" for more details.
Willy.
Ralph
>
> > <snipped>
> > As they have different names storage is irrelevant. If you add
additional
> > components to your stable, you might find it more convienent in the long
> > run
> > (and helpful to your sanity <g>) to separate them into different folders
> > with different LibIDs, and manage similar code with conditional
compiles.
> > But it really doesn't matter.
> >
>
> It seems that it does not matter (see answer I made to Willy above in this
> thread)
>
> > The order makes no difference.
>
> Humm... from our experience, it seems that this assertion is also false.
> FYI, we use the ATL Registrar component to make registration (using .rgs
> resources)
>
> So the result differs.
>
I meant that "functionally" it shouldn't make any difference. ie, if you
follow the path COM takes in resolving the references - everything will come
out all right. Things are confused a bit because you are using the same
GUIDS for both products.
HOWEVER, I have since learned that you can confuse the registry do to the
"last writer wins" philosophy or by importing a Reg file or forcing writes
to specific non-WoW locations.
: http://support.microsoft.com/kb/896459
> I wonder also why there are
> HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node
> and
> HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes ?
>
When you run a 32-bit application on Windows64 the application is running in
WoW (Windows on Windows). When it attempts to read from a location, say
"HKLM\Software\xxxx", as it would if running under Windows32, it is actually
redirected to read from "HKLM\Software\Wow6432Node\xxxx".
-ralph
Ralph
> Hello,
>
> We have another question related to this problem:
>
> Can a 64 bits process (or dll) is able to access a TypeLib embedded in a
32
> bits dll (or the opposite)?
>
Why would you want to?
On Windows64 32-bit applications can not load 64-bit Dlls and 64-bit
applications can't load 32-bit Dlls. But as there is nothing in programming
that is impossible, I suppose one might come up with a way to extract TypLib
information out of any file. But what would you do with it?
>
> Using ProcessExplorer, we saw a 64 bits dll listed in our 32 bits process
> (and, yes, we are sure that this dll is 64 bits).
>
Processes themselves only use GUIDS - subsquent information is returned by
reading the registry, and as 32-bit processes can't load 64-bit Dlls then I
suspect this is only a reflection of "registery confusion". <g>
But I'm often wrong. Hopefully Willy will soon be by to set us all straight.
<bg>
-ralph
Olivier
Hello Willy,
> do you mean you can register whatever version of a dll with whatever
> version of regsvr32?
Yes, exactly.
In the meantime, I was thinking about this, and maybe that regsvr32 is able
to run the correct version of itself to register correctly the dll. I mean,
when trying to register a 64 bits dll using the 32 bits version of regsvr32,
this latter runs an instance of the 64 bits version of regsvr32, passing the
filepath of the dll as an argument (thanks to the ShellExecute() API for
instance)
Again, I don't know exactly how this works, but this works.
Olivier.
Olivier
>>
>> Can a 64 bits process (or dll) is able to access a TypeLib embedded in a
> 32
>> bits dll (or the opposite)?
>>
>
> Why would you want to?
>
> On Windows64 32-bit applications can not load 64-bit Dlls and 64-bit
> applications can't load 32-bit Dlls.
Yes of course I know this :(
But maybe this is different when accessing a resource (like a typelib)
embedded in a dll?
ProcessExplorer (v11.04) may also be wrong and displays inexact
informations...
> But as there is nothing in programming
> that is impossible, I suppose one might come up with a way to extract
> TypLib
> information out of any file. But what would you do with it?
Me? Nothing at all! But ATL yes! The ATL class IDispatchImpl loads the
associated typelib. This is also the case for anything related to COM event
management (the associated dispinterface is described in the typelib)
>> Using ProcessExplorer, we saw a 64 bits dll listed in our 32 bits process
>> (and, yes, we are sure that this dll is 64 bits).
>>
>
> Processes themselves only use GUIDS - subsquent information is returned by
> reading the registry, and as 32-bit processes can't load 64-bit Dlls then
> I
> suspect this is only a reflection of "registery confusion". <g>
I'm sure not. ProcessExplorer lists modules that have been loaded by a
process. I think that it does not know if a particular process uses COM
objects and so on...
Olivier.
Olivier
Hello Ralph,
> I meant that "functionally" it shouldn't make any difference. ie, if you
> follow the path COM takes in resolving the references - everything will
> come
> out all right.
I know this. I think that the problem (confusion) comes from registry
redirection/reflexion itself.
> Things are confused a bit because you are using the same
> GUIDS for both products.
"both products"? There is only one product that is compiled both in 32 and
64 bits. For me, this does not make any sense to change GUID due to the fact
we are targetting a different plateform (this is the same code). Moreover,
the 32 bits and 64 bits versions MUST be able to run simultanously on the
same (x64) plateform
> HOWEVER, I have since learned that you can confuse the registry do to the
> "last writer wins" philosophy or by importing a Reg file or forcing writes
> to specific non-WoW locations.
I think that the problem is again the registry redirection/reflexion
And, indeed, my conclusion is that this "strange" behaviour forces us to use
different GUIDs for each platform, and so, this requires also we use in our
application the correct GUIDs for each plateform.
> : http://support.microsoft.com/kb/896459
Thanks. I already read it.
>
>> I wonder also why there are
>> HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node
>> and
>> HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes ?
>>
>
> When you run a 32-bit application on Windows64 the application is running
> in
> WoW (Windows on Windows). When it attempts to read from a location, say
> "HKLM\Software\xxxx", as it would if running under Windows32, it is
> actually
> redirected to read from "HKLM\Software\Wow6432Node\xxxx".
>
ok I know this
is content in
HKEY_LOCAL_MACHINE\SOFTWARE\***Classes\Wow6432Node***
same as in
HKEY_LOCAL_MACHINE\SOFTWARE\***Wow6432Node\Classes***?
I think so.
My understanding is that:
HKEY_LOCAL_MACHINE\SOFTWARE\***Classes\Wow6432Node*** is accessed by 64 bits
processes (to gain access to the 32 bits COM ***out-of-proc** servers)
HKEY_LOCAL_MACHINE\SOFTWARE\***Wow6432Node\Classes*** is only accessed by 32
bits processes (for in-proc or out-of-proc COM servers)
Now, the (my) problem was that
HKEY_LOCAL_MACHINE\SOFTWARE\***Classes\Wow6432Node*** contains also
registration informations for COM in-proc servers. This did not make sense
for me but as it is just a 'reflexion' of keys, not a copy of, I'm ok with
this now
So, the COM infrastructure looks at the LocalServer32 and InprocServer23
sub-keys and ignores this latter in case of a 64 bits COM client?
Olivier.
Willy Denoyette [MVP]
Ok I see what happens, regsvr32 whatever version will spawn a new instance
of regsvr32 depending on the bit-ness of the target.
If the target is 32-bit, then SysWow64\regsvr32.exe will be launched, is the
target is a 64-bit DLL then the system32\regtsvr32 will be spawned.
This means that regsvr32 does the right thing no matter which version you
started.
Willy.
Willy Denoyette [MVP]
Are you sure that the 64-bit DLL was a COM DLL?
For instance, a 32-bit process loads the 32-bit and the 64-bit of the
ntdll.dll, part of each 32-bit process contains 64-bit code which is used
when calling into the kernel. Besides ntdll.dll there are other dll's loaded
that are 64-bit (wow64.dll, wow64cpu.dll etc..).
Willy.
Olivier
"Willy Denoyette [MVP]" <willy.d...@telenet.be> a écrit dans le message
de news: OO2AWQXe...@TK2MSFTNGP02.phx.gbl...
Yes, we are sure because this is one of our COM dlls compiled in 64 bits :)
ProcessExplorer and DependencyWalker tell us that this dll is 64 bits
Nevertheless, I will check this again.
Maybe a typelib resource can be accessed using RPC? I mean if a 32 bits
process requires this typelib (only) stored in a 64 bits module, then COM
may use RPC to access it (or a specific Win32 API that is only interested by
the resource)
Does COM exist as 32 bits and 64 bits on Windows64?
I think so.
Olivier.
Olivier
"Olivier" <to...@toonworld.com> a écrit dans le message de news:
%23SSBeme...@TK2MSFTNGP03.phx.gbl...
I checked this again and I'm sure I'm correct.
On the 64 bits dll listed as belonging to our 32 bits process,
ProcessExplorer tells me that the 'Mapping Type' is 'Data'
On another 32 bits dll (in fact the same dll compiled as 32 bits) listed
also in the 32 bits process, ProcessExplorer tells me that the 'Maping Type'
is 'Image' (I think that means 'Code')
That would confirm that Win64 is able to load data (like resources) stored
in a 64 bits dll into a 32 bits process?
This seems correct for me, since, in this case, data (typelib resource) does
not need the code stored in the dll :)
Interesting, does not it?
Olivier.
Willy Denoyette [MVP]
> Hello Willy,
>
> "Willy Denoyette [MVP]" <willy.d...@telenet.be> a écrit dans le
> message de news: OO2AWQXe...@TK2MSFTNGP02.phx.gbl...
>> "Olivier" <to...@toonworld.com> wrote in message
>> news:ewQ9a1Se...@TK2MSFTNGP03.phx.gbl...
>>> Hello,
>>>
>>> We have another question related to this problem:
>>>
>>> Can a 64 bits process (or dll) is able to access a TypeLib embedded in a
>>> 32 bits dll (or the opposite)?
>>>
>>> Using ProcessExplorer, we saw a 64 bits dll listed in our 32 bits
>>> process (and, yes, we are sure that this dll is 64 bits).
>>>
>>> Best regards,
>>>
>>> Olivier.
>>
>> Are you sure that the 64-bit DLL was a COM DLL?
>> For instance, a 32-bit process loads the 32-bit and the 64-bit of the
>> ntdll.dll, part of each 32-bit process contains 64-bit code which is used
>> when calling into the kernel. Besides ntdll.dll there are other dll's
>> loaded that are 64-bit (wow64.dll, wow64cpu.dll etc..).
>
> Yes, we are sure because this is one of our COM dlls compiled in 64 bits
> :)
> ProcessExplorer and DependencyWalker tell us that this dll is 64 bits
>
This is weird, 32-bit COM should not have an idea about the location of this
64-bit DLL, nor should DependencyWalker show this DLL, are you sure you
don't statically link?.
I would suggest you to forget about these tools and load the application in
the Windbg (or similar) debugger, set a breakpoint on library load (sxe ld
libname).
> Nevertheless, I will check this again.
>
> Maybe a typelib resource can be accessed using RPC? I mean if a 32 bits
> process requires this typelib (only) stored in a 64 bits module, then COM
> may use RPC to access it (or a specific Win32 API that is only interested
> by the resource)
>
I would be very surprised if the 32-bit COM library would (could) load a
64-bit COM DLL into a process just to get at the embedded typelib info,
which is already present in the 32-bit COM dll.
> Does COM exist as 32 bits and 64 bits on Windows64?
>
> I think so.
Sure, the COM library (OLE32, oleaut32 etc..) is user mode code, only
libraries with the same bit-ness can/will be loaded in a user mode process
(except the ones I mentioned before).
Willy.
Willy Denoyette [MVP]
No doubt, I believe you are correct.
> On the 64 bits dll listed as belonging to our 32 bits process,
> ProcessExplorer tells me that the 'Mapping Type' is 'Data'
> On another 32 bits dll (in fact the same dll compiled as 32 bits) listed
> also in the 32 bits process, ProcessExplorer tells me that the 'Maping
> Type' is 'Image' (I think that means 'Code')
>
That's right, "Image" is the mapping type for code segments.
> That would confirm that Win64 is able to load data (like resources) stored
> in a 64 bits dll into a 32 bits process?
>
Sure, the OS can read whatever "file", but the OS loader will not "load" a
64-bit module in a 32-bit process (as a result of a LoadLibrary(Ex) call).
> This seems correct for me, since, in this case, data (typelib resource)
> does not need the code stored in the dll :)
>
Why would he need to load a 64-bit COM DLL, when the typelib info is already
present in the loaded 32-bit module?
There must be another reason why the 64-bit DLL is mapped into the 32-bit
process, I would love to repro this case but I can't :-(.
I wonder how you built the DLL and what version of the OS and VS you are
using.
> Interesting, does not it?
>
Sure it is, however I don't like the idea of wasting VAS because some
libraries (related but not the same) get mapped twice in the same process.
Imagine how much memory space you waste in a (32-bit!) process that loads a
bunch of COM server DLL's...
Willy.
Olivier
Because registry tells to COM where the required typelib is located. See my
previous posts, above in this thread, about order of registration of a COM
dll compiled both as 32 and 64 bits. As I learned it, the "last writer
wins".
In this scenario, the 64 bits version of our dll was the last registered. I
mean, I registered the 32 bits version and the 64 bits version of the dll,
in this order. If I register the 32 bits version in last, then the 64 bits
version is no more listed as belonging to our 32 bits process. In this case,
there is only the 32 bits version.
> There must be another reason why the 64-bit DLL is mapped into the 32-bit
> process, I would love to repro this case but I can't :-(.
No, I think that the (only) reason is that the required resource (typelib)
is embedded in the 64 bits dll.
> I wonder how you built the DLL and what version of the OS and VS you are
> using.
32 bits version is compiled using VC++6.0 on Windows XP Pro 64 bits
64 bits version is compiled using VC++2005 on Windows XP Pro 64 bits (same
seat)
>
>> Interesting, does not it?
>>
>
> Sure it is, however I don't like the idea of wasting VAS because some
> libraries (related but not the same) get mapped twice in the same process.
> Imagine how much memory space you waste in a (32-bit!) process that loads
> a bunch of COM server DLL's...
Indeed, I agree with you. BTW, I should mention that our product is
currently a mix of 32 and 64 bits COM modules. They interoperate through IPC
(when bit model differ). To achieve this, we have created our own "surrogate
process" because we also need to detect at runtime which version (bit model)
of a COM dll we need to use. Since our application is still 32 bits,
sometimes we don't use our surrogate infrastructure (because the bit model
does not differ) and sometimes we use it. That may explain the mix shown by
ProcessExplorer.
As an example: In one of our COM modules, we need to access a MS Access
database. When compiled as 32 bits, there is no problem to do this in this
COM module. When compiled as 64 bits, we use our surrogate infrastructure to
use the 32 bits version of MDAC/ADO, because the OleDB MS/Jet driver is not
available in 64 bits (except on Windows Server 2003 x64, and, AFAIK, there
is no redistribuable package for others x64 systems!).
Olivier.
Willy Denoyette [MVP]
Running Vista and WS2008 both 64 bit. Whatever the order of registration, I
only see a single DLL loaded.
I will now try to call an out-proc server (surrogate proc) and see whether
the marshaler is loading the typelib from the last registered DLL.
Willy.
Willy Denoyette [MVP]
news:%23uS7%23C6eI...@TK2MSFTNGP06.phx.gbl...
Did some more tests (in-proc, out-proc, COM+ etc) but I can't see any 64-bit
dll's getting loaded in a 32-proc.
Also, the typelib's are registered, for each 32 and 64 bit, under the same
key (the typelib UUID).
After registering a 32-bit DLL I see this :
HKEY_CLASSES_ROOT\TypeLib\{D1326A09-C866-4D09-8980-A400FA581D74}\1.0\0\win32
with a REG_SZ that looks like:
E:\Develop\netfx\Interop\atlmt\ASimpleCom\SimpleCom\Release\simplecom.dll
After registering the 64-bit version on the same component (same GUID's), I
have a second key under the typelib key.
HKEY_CLASSES_ROOT\TypeLib\{D1326A09-C866-4D09-8980-A400FA581D74}\1.0\0\win64
with a REG_SZ that looks like:
E:\Develop\netfx\Interop\atlmt\ASimpleCom\SimpleCom\x64\Release\simplecom.dll
that means that both win32 and a win64 typelib's are getting registered,
each containing the path of the COM server DLL.
This under Vista-64 and WS2008, don't know if this differs from 64-bit XP.
Willy.
Olivier
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).
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
Again, for me, there is no "real" problem in loading a 64 bits dll as a
*data file* in a 32 bits process (I think this is what COM is doing when
looking for a typelib resource). As you already mentioned it, the ONLY
problem is that, depending of order of registration, sometimes we have only
the 32 bits version of the module and sometimes we have a mix of both...
Olivier.
Willy Denoyette [MVP]
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).
> Again, for me, there is no "real" problem in loading a 64 bits dll as a
> *data file* in a 32 bits process (I think this is what COM is doing when
> looking for a typelib resource). As you already mentioned it, the ONLY
> problem is that, depending of order of registration, sometimes we have
> only the 32 bits version of the module and sometimes we have a mix of
> both...
>
Maybe there is no "real" problem with this, but, there must be a reason why
MS has changed the typelib registration/loading on the latest OS'ses. My
guess is that they too didn' like ;-) the extra resource consumption related
to the loading of the "latest registered" typelib.
Willy.
Olivier
>> 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?
>> Again, for me, there is no "real" problem in loading a 64 bits dll as a
>> *data file* in a 32 bits process (I think this is what COM is doing when
>> looking for a typelib resource). As you already mentioned it, the ONLY
>> problem is that, depending of order of registration, sometimes we have
>> only the 32 bits version of the module and sometimes we have a mix of
>> both...
>>
> Maybe there is no "real" problem with this, but, there must be a reason
> why MS has changed the typelib registration/loading on the latest OS'ses.
> My guess is that they too didn' like ;-) the extra resource consumption
> related to the loading of the "latest registered" typelib.
>
> Willy.
>
I agree with you.
Olivier.
Willy Denoyette [MVP]
> 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.