What does HackerNews think of hangover?

Hangover runs simple (Win64/)Win32 applications on arm64/(ppc64le)/x86_64 Linux and x86_64 Mac

https://github.com/AndreRH/hangover

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.

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.

There's definitely a way to use Wine along with binfmt_misc to run x86 apps on ARM or other architectures.

edit: Hangover lets you run x86 programs via Wine on ARM platforms: https://github.com/AndreRH/hangover

Wine Is Not an Emulator ;-)

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 )

Well, the GP was talking about getting wine to run. Your examples cover either instruction set emulation or ABI emulation, but not both. In order to get wine to do something useful om ARM mac, it would need to do both while somehow being optimized to not suffer too much performance loss, and without suffering too much compatibility loss.

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.

[0] https://github.com/AndreRH/hangover