Why 64-bit programs can't load 32-bit plugins

[AndrewAPrice]

I have used a lot of tools in my time by Adobe, Autodesk, Microsoft, Oracle, and one thing that annoys me is the ability for something to fail because I have a mixture of 32-bit and 64-bit software installed.

For example, many 32-bit tools that try to interface with Oracle refuse to run if I have a 64-bit copy of Oracle installed. I also sometimes find myself using a 64-bit program, and really need to use a legacy 32-bit extension, but it won't work with anything but the 32-bit version of program.

I was thinking, especially with so many companies (Microsoft, Adobe) focused on supporting legacy solutions, why they don't invest in a solution for running 32-bit extensions under 64-bit software.

My solution is for 64-bit programs to have a 32-bit stub that can load 32-bit extensions in. The 32-bit stub uses IPC to enable the 64-bit program and the 32-bit extension to communicate with each other. It may add a significant performance overhead, but I think this is acceptable over simply not being able to use the extension at all.

Also from an OS perspective:
How about letting applications contain both 64-bit and 32-bit code? Such as a system call upon entering the function of a dynamically linked library switches to 32-bit, and 64-bit upon exiting. The program could consist of threads executing both 64-bit and 32-bit blocks of code simultaneously. Of course, in 32-bit mode you'll be limited to 4GB of virtual memory. This wouldn't solve every problem, but at least give software engineers something to work with when designing their plugin architecture or using legacy libraries.

[bluemoon]

Some properly written program can be compiled to both 32-bit and 64-bit, however, most program are poorly written that breaks on one or other architectures. One example of poor practice is pointer to integer casting.

Furthermore, 64-bit program usually uses different calling convention, so to properly run them you need to insert wrappers upon (dynamic) linking, it is possible.

However, I think this is not about OS compatibility, but stability. it is simply not possible to test the 32-64 bridge with infinite number of existing softwares, and there is no reason to take the risk for unstable software with commercial OS.

The program could consist of threads executing both 64-bit and 32-bit blocks of code simultaneously.

Why on Earth you want such an execution environment?


ps. In fact, multiple architecture binary bundles exists on Mac OS X for many years.

[Owen]

I have used a lot of tools in my time by Adobe, Autodesk, Microsoft, Oracle, and one thing that annoys me is the ability for something to fail because I have a mixture of 32-bit and 64-bit software installed.

For example, many 32-bit tools that try to interface with Oracle refuse to run if I have a 64-bit copy of Oracle installed. I also sometimes find myself using a 64-bit program, and really need to use a legacy 32-bit extension, but it won't work with anything but the 32-bit version of program.

I was thinking, especially with so many companies (Microsoft, Adobe) focused on supporting legacy solutions, why they don't invest in a solution for running 32-bit extensions under 64-bit software.

My solution is for 64-bit programs to have a 32-bit stub that can load 32-bit extensions in. The 32-bit stub uses IPC to enable the 64-bit program and the 32-bit extension to communicate with each other. It may add a significant performance overhead, but I think this is acceptable over simply not being able to use the extension at all.

Many developers do. Most 64-bit web browsers, for example, contain surrogate plugin hosts for 32-bit plugins; or they get run via NSPluginWrapper

Also from an OS perspective:
How about letting applications contain both 64-bit and 32-bit code? Such as a system call upon entering the function of a dynamically linked library switches to 32-bit, and 64-bit upon exiting. The program could consist of threads executing both 64-bit and 32-bit blocks of code simultaneously. Of course, in 32-bit mode you'll be limited to 4GB of virtual memory. This wouldn't solve every problem, but at least give software engineers something to work with when designing their plugin architecture or using legacy libraries.

From a practical perspective, nothing stops you having both in the same process. You could use the fixed layout required by the SYSCALL instruction to know that the 32-bit CS is 2 entries before the 64-bit CS (Nobody guarantees this, but in practice, it is pretty much guaranteed to be true), or you could use your OS' LDT functions (where present) to construct yourself a 32-bit CS.

The big problem is that now you have to get code for loading 32-bit programs, and the environment to run them, in one process. Types like FILE are going to be incompatible between 32-bit and 64-bit libraries, and for many systems this will be part of the defined ABI. You now have two copies of many support libraries loaded in each process, probably not at all interoperable.

For call translation between different bitnesses, you would firstly need type information available to the linker, and you would still have the issue of translating pointers between the two environments. You could constrain the 64-bit process' malloc to 32-bit pointers, but then the transition to 64-bit has become a net loss anyway (because the 64-bit process will be using 64-bit pointer types)

The best you could achieve is probably something along the lines of the translation API Microsoft added to Windows to ease the Win16-to-32 transition, which required full type information to be passed. Even then, the application is still going to have to be coded specifically to be able to invoke 32-bit libraries. And at that point, you have to ask the question of whether the extra requirements of IPC are really that high.