Load 32-Bit Shared Library from 64-Bit Application

Load 32-bit shared library from 64-bit application?

No, you cannot load a 32-bit library in a 64-bit application through conventional means.

There are some clever hacks out there such as having a 32-bit application which loads the library and exports the functions through an IPC interface, but if you have the option to compile the library as 64-bit, then that is by far the best choice.

Load 32bit DLL library in 64bit application

You can only load a 32bit DLL into a 64 bit process when you are loading the dll as a datafile. You can't execute the code. (http://support.microsoft.com/kb/282423)

Microsoft recommends that you use interprocess COM to use 32 bit code with a 64 bit application. Here's an article explaining the process.

running 64-bit application with 32-bit shared object

You cannot mix 32 and 64 bit code in the same process. So option 1 is out but the other two are fine.

Loading a 32bit .so library in a 64bit JVM

No.

You can not load a 32-bit library into the address space of a 64-bit process.

Use 32bit shared library from 64bit application?

You must be consistent. A 64-bit application can only use 64-bit libraries and a 32-bit application can only use 32-bit libraries. Both work; either choice is fine, and it's possible to compile the same code for both systems.

If you go for 'all 32-bit', use:

• gcc -m32

If you go for 'all 64-bit', use:

• gcc -m64

Sometimes, I'll tell make that the C compiler is gcc -m32 (or -m64) rather than just gcc to ensure the right value is used everywhere.

Using 32 bit library from 64 bit project - .NET

You have to use some kind of surrogate process and IPC to access a 32 bit dll from a 64bit process.

Some time ago I wrote the LegacyWrapper project that hides this behind a simple API call. You may want to see the corresponding blog post for technical details.

Edit: Since Version 2.1, LegacyWrapper also supports loading 64bit DLLs from a 32bit process.

Using 32-bit library from 64-bit application with perl or neko

Neither Perl nor Neko are going to help you consume this 32 bit library in your 64 bit process. Were you to try to use either Perl or Neko you would just be injecting even more layers in between your two modules.

You will need to use IPC of one form or another. There are many ways to do that. You could create a 32 bit C# host process for the 32 bit library, and then communicate between the 32 and 64 bit C# processes using one of the standard .net IPC frameworks.

However, this does look like a good fit for an out-of-process COM solution. Create an out-of-process COM server that exposes the functionality of the 32 bit DLL. Consume that COM server from your 64 bit process as you would any other COM server.

---

Related Topics