4 ms·
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 th
by rnd0 5y ago
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).
- zamadatix 5y agoQEMU 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.
- oshiar53-0 5y agoQEMU 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.
- spijdar 5y ago> 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)
- zozbot234 5y ago> 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.
- comex 5y ago> The best you can do is have the "target" userland marshal calls to the native userland, translating across native and target ABI. Which is what Box64 does.
- oshiar53-0 5y agoEdit: 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.
- lukeh 5y agoAs I understand it, Rosetta 2 uses translated versions of the libraries too, but a single native kernel. I’m not sure what Windows does.
- twoodfin 5y agoYeah 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.
- dundarious 5y agoI 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.