Linking 32-Bit Library to 64-Bit Program

Linking 32-bit library to 64-bit program

No. You can't directly link to 32bit code inside of a 64bit program.

The best option is to compile a 32bit (standalone) program that can run on your 64bit platform (using ia32), and then use a form of inter-process communication to communicate to it from your 64bit program.

Can 32 bit and 64 bit work together?

In short: You can't link a 32-bit app to a 64-bit library.

You can run a 32-bit application, using 32-bit shared libraries on a 64-bit OS (at least all the popular 32-/64-bit processors such as AMD, Intel and Sparc). But that doesn't involve any libraries.

Longer answer: I was involved (on the outskirts) of some of the teams that designed the 64-bit Linux kernel for x86. There were briefly (compared to the whole project, the discussions lasted quite a few hours) some discussion as to how you could technically make this work. The short summary of this is that in 64-bit there are registers that aren't available in 32-bit. There is also the problem of memory addresses and the extra 32-bits in registers. All of these CAN be solved supposing the library itself "knows" that it's a 32-bit compatible library. But then we basically have a 64-bit library that is written to be a 32-bit library, and we've kind of lost the point.

The "more registers" may not apply to some processors, but the bigger address/bit-range of registers definitely apply to ALL 32- and 64-bit compatible processors. And I'm not aware of any single processor that allows a 32-bit code calling a 64-bit shared library or static library. It just doesn't work unless the code is specifically written to cope with that, which defeats the purpose of having a generic 64-bit library to support 32-bit apps.

Edit:

The above discusses linking one executable unit, e.g. an executable file, a shared library or a static library. That has to be all "one bitness", either 32 or 64 - no mixing.

When a process that talks to another process (e.g. a GUI app which displays status from a non-GUI process that), as long as the two processes use the same protocol [and typically, IPC doesn't allow passing of pointers anyway, so 32-/64-bit conversion isn't as big an issue], you can have one process that is 32-bit and another that is 64-bit.

Linking 32-bit libraries to a 64-bit .NET application and memory consumption

x86 and x64 can't be loaded into the same process. Are you sure that the reference isn't an AnyCPU assembly, or that the 32-bit reference doesn't have a 64-bit or AnyCPU version in the GAC?

Also note that on 64-bit Windows, DLLs in System32 are 64-bit. 32-bit ones are in SysWOW64.

32 bit library on 64 bit system

64 bit Windows is fully capable of running 32 bit applications. In fact, the default configuration for Visual C++ is to build an x86 application regardless of the operating system it is running on.

There are some gotchas you have to be aware of when running a 32bit app on 64bit Windows. For instance, there's registry redirection (to avoid it you pass KEY_WOW64_64KEY to e.g. RegOpenKeyEx). There's filesystem redirection, too. These are important things to have in mind when you are reading system configuration values, for example.

Also, be aware that you can't mix 32 and 64 bitness in the same process. Your 32bit app can't use 64bit DLLs or static libraries.



Related Topics



Leave a reply



Submit