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?

Saimon

Possible duplicate of Access x86 COM from x64 .NET – Grievous

In theory, there is a way. See my answer here. In practise, it has no meaning nowadays. Create a win32 wrapper and use IPC. – Ooze

Answer 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

Tense

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. – Saimon

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: #6523575 – Prefect

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

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

Windows surrogate processes seem like a good potential approach: https://mcmap.net/q/339526/-access-x86-com-from-x64-net – Grievous

Read the article, it only describes what to do, not how to do it. – Secessionist

Check my answer here however. There is a theoretical way. – Ooze

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

Lexine

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

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. – Jedlicka

Answer 3

John's answer is correct if you don't want to recompile your existing dlls; however that might be an option for you as well.

Our team is currently migrating our x86 FORTRAN code to x64 to increase the memory ceiling.

Sideline

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