"Willy Denoyette [MVP]" <willy.denoyette@telenet.be> a ?crit dans le
message de news: OFLiIWfeIHA.5208@TK2MSFTNGP02.phx.gbl...
"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?
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.
Running Vista and WS2008 both 64 bit. Whatever the order of registration,
I only see a single DLL loaded.