Hacker News Reader

Comment by spacedcowboy | Hacker News Reader

Find out on Monday :)

Either they’ve integrated Wine, or you’re screwed.

Wine is not an emulator, as you may know. It runs the executable directly on the processor, embedded in a Windows compatible runtime.

You probably mean something like Rosetta...

There's plenty of prior art beyond Rosetta to look at. MS has already done this for Windows on ARM, and simultaneously across ABIs via WSL. Linux offers QEMU-based "on the fly" emulation of different instruction sets based on execution-time examination of the ELF binaries. x86 BSDs have long offered Linux emulation. Even ChromeOS offers lightweight containers for Android and Linux apps.

Apple is actually pretty far behind the curve here, at least in terms of end-user-accessible features. Presumably that means they wouldn't have to innovate too much to get x86/ARM translation working, even for binaries that couldn't be readily recompiled to support the new chips directly.

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

You’re right, of course, and I did. It’s morning, I need coffee, have an upvote :)

Reply on news.ycombinator.com