Calling 32bit Code from 64bit Process

Question

I have an application that we're trying to migrate to 64bit from 32bit. It's .NET, compiled using the x64 flags. However, we have a large number of DLLs written in FORTRAN 90 compiled for 32bit. The functions in the FORTRAN DLLs are fairly simple: you put data in, you pull data out; no state of any sort. We also don't spend a lot of time there, a total of maybe 3%, but the calculation logic it performs is invaluable.

Can I somehow call the 32bit DLLs from 64bit code? MSDN suggests that I can't, period. I've done some simple hacking and verified this. Everything throws an invalid entry point exception. The only possible solution i've found so far is to create COM+ wrappers for all of the 32bit DLL functions and invoke COM from the 64bit process. This seems like quite a headache. We can also run the process in WoW emulation, but then the memory ceiling wouldn't be increased, capping at around 1.6gb.

Is there any other way to call the 32bit DLLs from a 64bit CLR process?

Solution 1

You'll need to have the 32-bit dll loaded into a separate 32-bit process, and have your 64 bit process communicate with it via interprocess communication. I don't think there is any way a 32-bit dll can be loaded into a 64 bit process otherwise.

There is a pretty good article here:

Accessing 32-bit DLLs from 64-bit code

Solution 2

You need to write your executable processes as 32-bit processes (versus Any CPU or x64) so that they'll be loaded with WoW32 for Vista. This will load them in the 32-bit emulation mode and you won't have the entry point problem. You can leave you libraries in AnyCPU mode, but your executables have to be compiled as x86.

Comments

[David J. Sokol]

That's the 64bit -> COM -> 32bit thing i Was describing. After reading that article and trying to get the sample to work, I decided that there has got to be a better way. At least I hope so.

[StrayPointer]

It sounds like they have considered this, but need the increased memory ceiling that 64-bit offers

[Helge Klein]

John's answer is correct. There is no way to have 32-bit and 64-bit modules mixed in one process. You need to start a second process. See also my answer here: stackoverflow.com/questions/6523075/…

[moleboy]

You don't necessarily need to use COM+ wrappers, but you do need to use a 32-bit process.

[Matt]

this works as long as you don't have any 32bit 3rd party assemblies (without the source code) you need to add as reference...

[Matt]

One half is true: 32 bit processes run on a x64 machine if you compile them as x86. But if your executable is x86 and your libraries are AnyCPU - the just in time compiler will make x64 code out of them which makes them incompatible with the (32 bit) executable. So, everything including the assemblies must be either x86 or AnyCPU.

[John B. Lambe]

This is correct. See Microsoft's page: msdn.microsoft.com/en-us/library/windows/desktop/…

[StayOnTarget]

Windows surrogate processes seem like a good potential approach: stackoverflow.com/a/359389/3195477