16

I have a shared library that is compiled as 32-bit. Can I use it from a 64-bit application or do I need to compile the shared library as 64-bit as well?

phuclv
  • 37,963
  • 15
  • 156
  • 475
Brian
  • 2,375
  • 4
  • 24
  • 35
  • 2
    What OS? It probably matters. – Paul Tomblin Apr 19 '11 at 18:29
  • 1
    @Paul: it actually shouldn't matter. Assuming x86-64, the processor at any given point is either in long mode (64-bit), protected mode (32-bit), or real mode (16-bit). When a thread is scheduled, the mode is set to match the process which can only be one of those. It is a matter of how x86/x86-64 works at its core. – Evan Teran Apr 19 '11 at 19:07
  • +1 for asking something seemingly obvious, but this makes it really obvious. – TheBlastOne Oct 17 '12 at 15:59
  • @EvanTeran **OS matters** because it can make a [thunk](https://en.wikipedia.org/wiki/Thunk#Interoperability) to allow 64-bit process to call 32-bit libraries and/or vice versa. For example 32-bit Windows allows 16 and 32-bit code to call each other. Or ARM64 Windows have a thunk for ARM64 and x86-64 code to interoperate. In 64-bit it's simply because no modern OS writers choose to implement the thunk – phuclv Jul 18 '23 at 06:46
  • @phuclv, It would be very hard to get right... but sure, I suppose you could have a thunk which invokes a system call that copies the arguments to a low address, changes the process's mode to 32-bit, then calls the function, then copies any results back, then will restore the process mode, and finally return. But the mode is per **process**, so you'd have to either suspend any other threads in the process, or literally run it in another process and use IPC as mentioned in my answer below. You're right that it's **technically** doable... but it would be have severe limitations. – Evan Teran Jul 18 '23 at 13:42
  • As a follow up, if you implement threads as independent processes that "happen to have the same pages mapped", you could do this per thread... but again the complexities are just stacking up. it would be a nightmare to implement correctly, and definitely would have pretty bad performance, hence why no OSes choose to implement such a mechanism. But it could "work" – Evan Teran Jul 18 '23 at 13:45

2 Answers2

17

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.

Evan Teran
  • 87,561
  • 32
  • 179
  • 238
  • This clever hack you mention still loads the DLL in a 32 bit process. Do you know of any of these hacks that load the 32 bit DLL in a 64 bit process? – John Dibling Apr 19 '11 at 21:06
  • 1
    @John: nothing that will work. You can of course do something like allocate memory in your process and manually read the binary code from the 32-bit dll into it. But the processor will treat it as 64-bit instructions which will not operate correctly. It simply cannot be done with the x86-64/x86 architecture. – Evan Teran Apr 19 '11 at 21:20
8

You cannot load dynamically or statically a 32-bit library from a 64-bit application or vice versa.

There are a number of work-arounds that I am aware of:

  1. Make a 64-bit version of the DLL
  2. Make a 32-bit version of the application
  3. Introduce a COM proxy object (also called a surrogate) as a communication intermediary. Described here.
  4. Host the DLL in a separate (32-bit) EXE and use an IPC technique

There are a number of inter-process communication (IPC) techniques. Here are a few examples:

Community
  • 1
  • 1
cdiggins
  • 17,602
  • 7
  • 105
  • 102
  • 3
    +1, even though shared memory, shared files, database tables, RFC, COM, and video screen poking are missing on the IPC techniques list ;) in other words: I suggest to "There are a number of inter-process communication (IPC) techniques:" you add a "some of which are:" phrase. – TheBlastOne Oct 17 '12 at 16:02