Can 32 bit and 64 bit work together?

Question

Can 64 bit library work in a 32 bit application? For example, my application GUI uses 32 bit Qt. And my business core is a 64 bit library. The OS is 64 bit. Can they work to

Answer 1

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.

Answer 2

If you run on Windows, then your application compiled for 32b can run on a Windows 64b host system: take a look at the WOW64 subsystem that's built into 64b Windows.

Having said that, you can not mix code compiled for 32b with code compiled for 64b. Meaning a library that was built for 32b can not be linked against 64b code, and vice versa. (Different calling conventions, stack frame layout, excepting unwind, ...)

Answer 3

I'm working on an application that does exactly this. The application core is x64 (and uses Qt), but it has to communicate with some equipment, for which I only have 32bit library from manufacturer. The way I implemented it is having two applications 64bits for core and GUI, and 32bits that controls the equipment and communicates with the main applications using QSharedMemory. Both apps are based on Qt (64 and 32bits correspondingly).

Answer 4

Yes, but it is a major nuisance.

First, a kernel is different from a library. Typically, a library is made visible in your process’ virtual address space; it shares the address space with your own code. Calling a library routine is simply a subroutine call.

In contrast, to request services from the kernel, your process executes a special instruction to generate a trap. This trap causes the processor to do some special things that include saving your process’ registers and other state in memory (or in special processor registers that you cannot normally access), changing various modes in the processor to make them suitable for the kernel, and changing the program counter to point to instructions for the kernel. Then the kernel is running. At this point, the kernel might be running in 64-bit mode while your process was running in 32-bit mode. However, the kernel is designed to be aware of these differences. When your kernel inspects your process to see what you are requesting, it looks for information and data structures knowing that your process was running in a 32-bit mode. A kernel can support both 32-bit and 64-bit processes, it just treats each type of process differently.

This presumes, of course, that the 64-bit kernel you are using supports 32-bit processes.

Normally, when you call a library, you want it to be the same mode as your code, because a normal library call is just a subroutine call; it does not generate a trap and does not change processor modes. If there were a critical need to call routines in a 64-bit library from a 32-bit process, then you could create a helper 64-bit process. Your 32-bit process would package up a request for a library call and send that request to the 64-bit helper process by some form of interprocess communication. That helper process would call the library routine and send the results back.

Naturally, this adds significant overhead to each library call, so it is something you want to do only if there is a great need and no better alternative.