I'm not convinced Apple will abandon x86 entirely. A lot of high-end Macbooks Pro are bought for software developers looking for Docker support, and that gets messier when you're developing for multiple architectures. (Then again, maybe it's a good thing if you like AWS Graviton.) The product that would benefit the most from ARM is the Macbook Air, so it's possible they just do that.
Apparently Windows supports ARM, so in theory Apple will continue to support Bootcamp.
> (notably, one thing Apple does not need to give up is Windows support: Windows has run on ARM for the last decade, and I expect Boot Camp to continue, and for virtualization offerings to be available as well; whether this will be as useful as Intel-based virtualization remains to be seen).
Windows may support ARM. Yet the reason most people want Windows is compatibility. And if Windows ARM doesn't run most of their software then it's a step backward for them.
It might give a small boost to Windows-on-ARM that Microsoft has been trying for over a decade. Porting a typical windows app might be easier than porting to Mac/Linux because you still have DirectX and all the Windows libraries.
There's also x86 emulation on ARM. It's slow, but it might be enough to run that 20 year old business app.
Windows ARM seems to be a bit faster than that running x86. An older video showed pretty good performance: https://www.youtube.com/watch?v=DRBMBkL7SCM . Using an abstraction layer to convert system library calls to call native ARM system libraries instead so you don't have to emulate x86 versions of the system libraries.
This is the same concept box86 implements on Linux. https://github.com/ptitSeb/box86 . It's good enough to run lower end Linux games on a Raspberry Pi 4
Wasn't Intel saber-rattling about patent lawsuits when Microsoft announced that Windows for ARM would run some x86 apps via emulation? [1]
While I don't know what became of that, I can see Microsoft working out a deal with Intel because Windows is still huge on x86 and wasn't going anywhere.
On the other hand, if Apple is planning to completely drop Intel in favor of ARM and wants to implement x86 emulation, I can't see Intel letting OSX ARM emulate x86 without some form of resistance.
But what IP would be violated for x86 emulation? It's clear that Intel only threaten chipmaker who tried to add x86-emulation-acceleration ISA to the silicon. x86 ISA is complete 17 years ago, which mean a lot of patents has been expired today.
The rest of the PC world includes a lot of desktops, and the cost/benefit analysis there is very different - power consumption matters little, and games demand top-of-the-line performance. So I don't think it'll move to ARM wholesale anytime soon.
Apple is unlikely to waste engineering resources and product resources on something they don't care about. Hackintoshes are largely an enthusiast phenomenon that doesn't overlap much with their core market of people willing to spend a premium on hardware that "just works" and looks nice. For the last 10 years Apple hasn't lifted a finger to stop them , why would they start now?
The danger is not so much T2 chips or the like, because that can easily be defeated in software, but locking down peripheral support would be. For instance if they only support their own custom graphics hardware that would be a problem. This is what Apple tends to do so it's the most likely scenario.
They did waste legal resources going after commercial Hackintosh clones, though, and they might want to prevent something similar in the future. And once they have their own unique CPUs, adding a CPU ID check is trivial.
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.