Re: COM dll server registration on Windows 64 bits
"Olivier" <toon@toonworld.com> wrote in message
news:OuZ7lEfeIHA.2268@TK2MSFTNGP02.phx.gbl...
"Olivier" <toon@toonworld.com> a ?crit dans le message de news:
%23SSBemeeIHA.4312@TK2MSFTNGP03.phx.gbl...
Hello Willy,
"Willy Denoyette [MVP]" <willy.denoyette@telenet.be> a ?crit dans le
message de news: OO2AWQXeIHA.5900@TK2MSFTNGP02.phx.gbl...
"Olivier" <toon@toonworld.com> wrote in message
news:ewQ9a1SeIHA.1208@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
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.
I checked this again and I'm sure I'm correct.
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.