Running applications on a different architecture than the one for which they were compiled is a common occurrence, not in the least with Apple’s architectural migration every decade or so. It’s also commonly used with for example ARM, OpenRISC, and RISC-V systems to run applications that are only available for x86 or x86_64. While QEMU and kin are often used here, they’re pretty resource heavy, which is where an option like Box86 and its 64-bit sibling Box64 are attractive options. Unlike QEMU, both offer dynamic recompilation and redirection of dynamic library calls to native libraries, including those for SDL and OpenGL.
Both are available on GitHub under an MIT license, with Box64 probably the most interesting these days as applications and games have moved on to a 64-bit only world. The only hard requirement that Box64 has for a host system is that it is little-endian, which is a pretty easy requirement to meet. The most recent release was on March 10th, with Box86 0.3 and Box64 0.2.2. As essentially a translation layer, it does not offer full compatibility with every bit of software out there, but it’s already good enough to run Steam, GoG, and Epic Game Store clients and install and run Windows games via Wine for x86.
A simple set of benchmarks comparing it with QEMU and FEX (another emulator) shows it to run both more applications, and with significantly better performance.
Could either box64 or box86 be used to run a VirtualBox VM on a non-x86 system? So you’d have something like a raspberry pi (ARM) running a VM, the guest OS (Linux or Windows) would then think itself to be on x86 hardware and any software within that VM would run perfectly normally (if a bit slowly).
Hi there! There’s already a Wine spin-off for Raspberry Pi.
Generally speaking, a high-level emulation is preferred these days.
It can be used nicely, if mainly API calls are being used and no actual number crunching is required. As it’s usual with graphical systems like Windows or Mac OS. These API calls are then essentially being converted between two platforms, with an extra machine language conversion (CPU emulation) as a part of it.
Back in the 90s, this was being done by Insignia’s SoftWindows (the early m68k version), afaik. Parts of Windows 3.1, mainly runtime libraries, were being ported to Mac 68k code.
But Mac OS for Power PC platform itself used such a high-level emulation, too. The PPC versions kept parts of the old Motorola 68000 code intact and called their API functions through an built-in emulator.
A full emulation, way down to the hardware level is much more resource hungry by contrast. A high-level approach can reach near native speed however, especially if no number crunching is involved.
You’ve given me an idea… SoftWindows on MacOS 7.6 on an Amiga 3000…
If it can’t be run on a Babbage Analytical Engine, it’s probably not worth running at all….
I remember DEC having similar software for their Alpha architecture.