There's also the x32 ABI
, which gives you the advantages of 64-bit mode in a 32-bit address space.
Good for embedded, where everything can be rebuilt for x32. Apple Watch uses an analogous ABI with 32-bit pointers on AArch64. But it's not quite as suitable for desktop because with x32 you need three
sets of libraries. Assuming everything whose developers are willing to build and test on x32 is x32, you still need the x86-64 libraries for x86-64-only applications and the x86 libraries for x86-only applications. Its failure to catch on is part of why Linux kernel developers had begun to consider dropping it
by December 2018.
Sik wrote:what is Canonical's idea about what to do with 32-bit programs, wrap them in a VM automatically or expect users to run their own VM?
Canonical expects each application's publisher to offer a snap with the application and the 32-bit core libraries. (A snap is a container, which is lighter weight than a full-on VM.) If your application's publisher went out of business in 2010, too bad.
tepples wrote:Run only 64-bit Windows programs, which would require ensuring that FCEUX (Win32) and FamiTracker are 64-bit clean
Discussion of this with respect to FCEUX continues in the thread: Catalina Wine Killer
With respect to FamiTracker:
nyanpasu64 has announced in the FamiTracker Discord server an intent to resurrect cpow's port of FamiTracker to Qt.
With respect to bgb, a proprietary Game Boy debugger: beware is providing experimental Windows x64 builds.
calima wrote:bugs allowing one to escape a container.
Such bugs exist in ZSNES. A Super NES program using one of the coprocessors can launch native i386 code using an out-of-bounds DMA.