"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.