Since it's not immediately clear looking at the repo, and porting it has been a side project of mine, I'll go ahead and add that PowerPC is one of the other non-ARM platforms supported. Both on box64 and box86, although ppcle is still a mess of a target triplet.
I'm also aware that it should work on LoongArch64!
Box64/86 is frankly not very pretty or elegant, but it's very surprising how much can be coerced to run through it, and by wrapping native libraries it can achieve staggering performance compared to QEMU or other full system emulators.
As in, you can actually use this to play games and run applications at usable speeds. Playing x86/x64 games on my POWER9 system has been gratifying ;-)
> I'll go ahead and add that PowerPC is one of the other non-ARM platforms supported. Both on box64 and box86, although ppcle is still a mess of a target triplet.
Unfortunately no, it needs little-endian for both 64 and 32 bit modes, which means that, practically, it's limited to systems with POWER{8,9,10} CPUs, along with a smattering of other (relatively) modern SoCs with LE support.
However, most 32 bit PowerPC cores did implement a sort of LE support, by munging memory addresses on reads/writes to word aligned scalars, and letting the OS kernel fix up misaligned and non-scalar operations. This looked like LE to the user process, although it resulted in real-mode memory being BE.
The caveat is, of course, the kernel has to be running as LE, which would require firmware/hardware support (most PPC boards are designed to run BE), or for the kernel to swizzle memory to/from said firmware/hardware.
Another possibility would be to run an LE userland under a BE kernel, which Linux does support. The caveat is the kernel expects all syscalls and ioctls to be the kernel's endianness, so either you handle the swizzling in the kernel, or pass the responsibility to the userland.
I apologize if this is too critical; but this seems to have a lot of caveats and is not only not portable -but almost anti-portable.
What's the advantage of this over something that can run on BSD like Qemu? (I was going to ask about BSD hypervisors like vmm, bhyve and then realized they're i386/amd64 specific).
QEMU is a full system emulator, Box64 emulates the app but tries to use native versions of libraries. This is the approach Microsoft and Apple use for running x86-64 code on ARM64 as it is more performant than full system emulation and it allows apps to run in a more integrated way.
QEMU softmmu is a full system emulator. There's another mode of QEMU build (qemu-user) that emulates userspace applications (just like Rosetta and WoW) and even lets you link to native libraries.
I'd be interested to learn more about this. My experience with qemu's usermode emulation is it only wraps syscalls and some ioctls. So you need a complete userland in the target arch.
In particular, it doesn't really wrap any DRM interfaces very well/thoroughly (as of when I tried), so you couldn't get 3D hardware acceleration working.
box64 bypasses this problem by just wrapping the native mesa libraries, avoiding opening that can of ioctl worms.
(To my knowledge WoW is the same in that it doesn't emulate the entire userland stack up to the syscall layer but can wrap calls to DLLs to native ones, not unlime the Hangover project does for x86 wine on Aarch64/ppc64le Linux)
> My experience with qemu's usermode emulation is it only wraps syscalls and some ioctls. So you need a complete userland in the target arch.
Yes, but that's required because the native userland would have a totally different ABI, so it's just not going to work with the target code even in emulated form. The best you can do is have the "target" userland marshal calls to the native userland, translating across native and target ABI. But even that is likely unfeasible in the general case.
Edit: I confused QEMU usermode with something else. QEMU seems to only do syscall/ioctl translation at the moment. My sincere apologies (I can't delete the comment).
Maybe library call stubbing (not x64 exclusive) could be my next project.
I think you're mixing up WSL2 and x86 (is x64 out yet?) emulation for Surface (running on aarch64). WSL2 runs a full Linux kernel on top of the Windows kernel, to be able to run Linux binaries with high compatibility (and good performance). x86 emulation translates a Windows x86 binary into a Windows aarch64 binary, so there is only the Windows kernel. Rosetta 2 works like this too. And so does box86/64.
So x86 emulation, Rosetta 2, and box86/64 all use translated binaries and a single kernel.
At least, that is my understanding.
I defer to you on whether Rosetta 2 is translating libraries as well (as opposed to box86/64's approach which is to use some native libraries), I don't know.
Yeah I was surprised when Apple didn’t go that way for Rosetta 2, especially after just a year or so prior forcing all Mac apps onto a single 64-bit runtime.
Does anyone have handy perf numbers for both box64 and qemu? Everyone says "it's slow" but I'd love to see some benchmark numbers for relative performance.
When in a Linux VM yes. Know however that box64 doesn't have exactly ideal perf characteristics, quite the reverse. Especially on that (recent) hardware.
Genuine question: Is there any naming issue with this project considering that there exists an emulator called Bochs which could be used to run x86_64 programs on non-x86_64 systems (albeit via the route of actually emulating a full machine)?
There's also 86box, which is somewhat similar to bochs, in that it emulates 8086-Pentium II era hardware.
But then again, there's plenty of bad naming issues with software... This one even has a different spelling, it's commendable.
There's a vaguely similar-ish project Hangover, which integrates Qemu and Wine, to run Windows apps on ARM and whatnot: https://github.com/AndreRH/hangover
As I understand it, Qemu in this arrangement only translates the code, without emulating hardware.
Alas, the project does not target Android anymore (at the moment)—it was one hope for running 90s games on a phone or tablet. Though the current status seems quite raw anyway, so things may change many times yet.
I'm also aware that it should work on LoongArch64!
Box64/86 is frankly not very pretty or elegant, but it's very surprising how much can be coerced to run through it, and by wrapping native libraries it can achieve staggering performance compared to QEMU or other full system emulators.
As in, you can actually use this to play games and run applications at usable speeds. Playing x86/x64 games on my POWER9 system has been gratifying ;-)