What does HackerNews think of hangover?
Hangover runs simple (Win64/)Win32 applications on arm64/(ppc64le)/x86_64 Linux and x86_64 Mac
https://www.phoronix.com/news/Wine-Hangover-2023-Open-Source
https://www.phoronix.com/news/Hangover-0.8.3
They were working on ARM and a bit of POWER9 for a while, before it had to be put on hold due to all the PE conversion work and resulting churn in WINE. Now it seems to have been restarted/rewritten.
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.
edit: Hangover lets you run x86 programs via Wine on ARM platforms: https://github.com/AndreRH/hangover
But seriously -- wine should have equal performance to running a program "natively" on windows because it essentially is running the program natively, just with different system DLLs that call back to the linux kernel instead of the NT executive.
Their implementation may be slightly slower in places, but it's not a problem inherent to Wine itself, and could always be fixed.
I know there's a stigma against running win32 apps on linux, and possibly rightly so, but there really isn't a reason why Wine couldn't be a legitimate runtime environment for linux. You can make 100% open source software that targets Wine, and never needs to use or link to proprietary software.
Wine has even been ported to architectures where there have never been native windows ports, like the ppc64le port of Wine.
(Wine/win32's binary interface is also easier to intercept and automatically translate/emulate calls for non-native architectures, which is the basis of WoW64 and x86 on ARM emulation, and in Wine land, projects like Hangover https://github.com/AndreRH/hangover )
It turns out such a project actually exists![0] But it seems to be in an early stage, and relies on infrastructure not exactly favoured in MacOS (QEMU, deprecated OpenGL). Apple could work to port it and polish it so it works with most apps, but why on earth would they invest so much in Windows compatibility?
IMHO, Apple has two reasonable choices here: Ignore Windows compatibility from now on, or do just enough so that Windows on ARM boots, and let Microsoft deal with the supporting x86 Windows headache and blame.