Explanation of how accessing 32-bit libraries from a 64-bit process works, and vice versa

Question

I was talking with a team member at work about converting our software suite from 32-bit to 64-bit, and the talk of using 32-bit dlls in a 64-bit process came up. He mentioned it's possible and that you can do the same thing to use 64-bit libraries from a 32-bit process, but didn't go into great detail about it other than mentioning having to use an inproc server or more complicated "boxing" techniques.

I do want to know how to do this for my own reference, but I'm more interested in how it actually works under the hood. How is it possible to access memory space that is not supposed to be visible between 32 and 64 bit processes? As mentioned, it also wouldn't hurt to know how to do this myself, I usually work with C++/CLI or C#.

Answer 1

other than mentioning having to use an inproc server...

This is not possible in-process, a 64-bit process cannot load and execute any 32-bit code. This would only be an issue if you have a dependency on unmanaged code, pure .NET code can always be jitted to the required architecture. A very nice goody provided by just-in-time compilation.

The only way to make such unmanaged code work is out-of-process by using a 32-bit helper process to give the code a compatible home. You get this almost for free if the unmanaged code is provided as a COM server, you can configure its AppId to run the server in a surrogate process. Just a matter of setting the registry keys correctly. If not then create your own .NET host application with the Platform target set to x86 so it will run as a 32-bit process. Get them talking to each other with a .NET process interop mechanism like WCF, Remoting, named pipes or sockets.