You can't do that yet, but it is a step in that direction. The general idea is that Wine is getting organized on two layers: the PE .dll libraries, which are similar to a Windows userspace, and the Unix libraries, which act as a sort of "kernel". The interface between the two is standardized and is kind of close to a system call interface (we actually call those "syscalls", even though what I can "kernel" is still a bunch of userspace .so libraries, so the processor is not really switched to kernel mode, and there is no hard enforcement of boundaries; also, many of these syscalls are much higher level than what you'd usually expect from a real kernel-userspace boundary).

Once all modules are converted (there are still a few missing, unfortunately the hard ones, but people are working on those), the PE world interact with the external system only through this "syscall" interface. The Unix world is required to be compiled for the external system's architecture, but the PE world can be whatever you want, provided that you do the appropriate things at the syscall interface.

For example, you can have 32 PE libraries and 64 bit Unix libraries, and at the syscall interface you switch the processor back and forth between 32 and 64. Or you can have x86 PE and ARM (or whatever) Unix, and you enable/disable an emulator at syscalls.

Wine Is Not an Emulator, so I doubt it will be able to run x86 apps on ARM.

This is a semantics debate, but it kind of is an emulator. Instead of emulating a CPU, it emulates the Windows API. That's obviously a major difference: One is inherently slower, while the other is inherently more complicated.

WINE originally stood for "Windows Emulator", but for trademark reasons it was changed to "Wine Is Not An Emulator". That's giving you some mixed messages now, isn't it? [edit] I just checked Wikipedia, and that's not true -- the name wasn't changed due to a trademark problem, it was changed due to a genuine confusion about what the term "emulator" meant.

It implements the Windows API.

And the Windows API is defined as "whatever Windows does", which Wine emulates.

> - The new Apple Silicon Macs are supported, including running x86-64 binaries under Rosetta 2.

Depends which ARM :)

Apple Silicon has special support for running ARM code with the "Total Store Order" memory model of x86.

JIT-compiling emulators for other ARM processors otherwise need to be stuff the code full of memory fence instructions to be able to utilise multiple cores properly. Optimising those away can be hard.

Not really though, it's just another layer which isn't wine. They might put effort in to help Rosetta translate, but wine is not an emulator.

I think some bits got added from the point where they got Wine working on OSX PPC back in the day.

I'm aware of what the acronym originally meant, but this was listed as working in the 6.x series for 64-bit x86 apps.

You can setup binfmt_misc to run x86 Windows binaries with Wine and Qemu on other architectures like ARM.

That probably won't work, WoW64 is running x86-64 on x86-32. You can combine Wine with QEMU to run x86-32 on AArch64 though.

That’s how I interpreted it as well for running 32-bit apps on 64-bit Host.