I disagree, you are exaggerating the difficulty of adapting an OS to another system running on the same architecture and assuming that Apple would not provide the necessary tools and would only accept Microsoft "reverse engineering" Apple Silicon. Also some of your posts show confusion about Windows on Arm, e.g where you say it's a subsystem. WoA is a full OS and should not be confused with X86 Windows. Nobody ever talked about running x86 Windows on AS natively, which is obvious impossible. I have zero doubt that Federighi meant what he said about booting WOA on AS, despite you saying the contrary.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Instead of Rosetta 2, why Apple doesn't make a Windows x86 emulator?
- Thread starter UBS28
- Start date
- Sort by reaction score
Right, and we already established in our recent discussion that some kernel patches (e.g. for AIC support) are necessary on the Windows side.
That is in addition to the fact, that Windows needs a full EFI.
Plus Wifi driver, Bluetooth driver, sound driver etc.
On the bright side, when you provide an DX12 driver you are getting OpenGL and OpenCL for free. Just need to install the OpenGL/OpenCL compatibility pack from Microsoft - which under the hood is an OpenGL/OpenCL->DX12 translator. Works for x64, x86 and arm64 apps.
In addition, this would be unprecedented. Drivers always coming from the SoC design company. Even for their own Surface line of products the drivers (including EFI) are coming from Qualcomm (when having Qualcomm SoC) or from Intel (when having Intel SoC).
People have to understand, that in case of AS, Apple designed the SoC and therefore Apple would have to provide the drivers including EFI.
And without commitment for driver development from Apple it makes no sense for Microsoft to start any activities here, because it would be moot.
Note, that this is not different than the current bootcamp situation on legacy Macs - it was just that Apple did not develop the SoC and therefore was not responsible for the drivers - they came from Intel (and from AMD etc..)
Last edited:
Apple Silicon is unprecedented and I don't think Apple would not want to make those drivers available, nor I think that would be a disproportionate effort
"Making those drivers available" does somehow sound, as if they were already existing. An EFI or Windows driver looks fundamentally different than a Mac driver for the same HW. So it would be a significant investment in manpower.
How significant an investment it would be is only speculation here. Again, I think Apple would do it.
Except it's not speculation, because the Asahi Linux people are putting considerable effort to develop their own drivers for Apple Silicon through reverse engineering because Apple is not providing them with any information that would make it easy for any third party to develop said drivers. Microsoft does not have to develop drivers for Intel chips, chipsets, or SoC or for Qualcomm chips, chipsets, or SoC because Intel and Qualcomm have done the development work for them. And the reason that they have done the development work for them is that Intel and Qualcomm develop their chips and chipsets for multiple companies, so they have an incentive to make it as easy as possible for operating system vendors to develop for their platforms.
Apple doesn't have to do that because there is only one customer for Apple Silicon. Apple. Not only that, but they have put forth considerable effort to make virtualization on Apple Silicon and under macOS easy and robust, which they did not have to do, mind you, but they did. In the interview with John Gruber, Craig Federighi goes so far to say that they think it's unnecessary for operating system vendors to put forth the effort to get their operating systems running natively on Apple Silicon because the virtualization frameworks and capabilities they provide consume such little overhead that putting forth the effort for such a small gain in performance over virtualization isn't worth it in Apple's view. Of course, some of that is marketing-speak, but to me they've made their intentions quite clear: they are not going to help operating system vendors get their operating systems running without virtualization.
They're not going to stop people from reverse engineering, like Asahi Linux is attempting, but they're certainly not going to help.
Certainly. As long as you don’t copy them you can emulate the functionality. My point was Wine is hit or miss in terms of what works. Some programs are fine, others don’t run well if at all.
Clean room development is as old as computers.
The question is why would Apple want to? When they went to x86 architecture it was a way to make Windows users comfortable with the Mac because they could still have a PC; I doubt that is as pressing a concern now.
Speaking of Asahi, Hector wrote this paragraph (part of Asahi's "Introduction to Apple Silicon" doc), and I think it sums up what's known of Apple's stance on other operating systems quite well.
Apple has engineered their hardware for their OS, and vice versa. They're not going to spend any effort on drivers for someone else's OS. As a company, they view that as a distraction from making their own stack the best it can be.
Unofficially, they have taken care in their platform security design to make sure that the door was left open for projects like Asahi Linux, and have even done things post release to make life easier for the enthusiast reverse engineering community. But that's the limit of what they're likely to do, barring a significant change in their leadership's thinking.
On "no explicit concessions" - Apple's approach to nearly everything is quite unique and not very friendly to anything but macOS. For example, nearly every peripheral subsystem of M1 has its own private microcontroller (a custom Apple core which is neither Firestorm nor Icestorm, but something smaller). That's fairly normal, but their approach to firmware for these embedded CPUs isn't. Every release of macOS ships with its own unique version of firmware, and the binary interface between firmware and OS is not stable - the macOS 12.3.1 firmware won't necessarily work with macOS 12.3.0, and vice versa. (In a lot of cases, the "firmware" is essentially the bottom half of the macOS driver for that peripheral.) This all works great for supporting Apple's own OS. Your firmware is always up to date, by definition, and if you install an older OS it gets to use its own firmware and not get confused by anything new introduced in subsequent updates. But what are other operating systems expected to do? The interfaces to each of these firmware images are private, and co-developed with macOS.
So far, Asahi's approach is to pick a specific macOS release, reverse engineer that version's firmware interface, and use its firmware for as long as they can. This is going to result in some pain for them, as every so often they're going to have to jump forward just to support new hardware or fix bugs, and without a stable interface that means another round of reverse engineering.
The main difficulty in my opinion are the drivers which would need to be written from scratch. And as @mr_roboto points out, Apple is using a nightly customized hardware which does not conveniently map onto existing driver models. For example, they have specialized processors that run a “half” of a C++ driver class, with another matching “half” in the OS kernel, with a custom remote method call procedure connecting the two. Doing thi on nacOS is easy, since the system and the tooling is built with these things in mind. Making it work - abs maintaining it - on a third party system sounds like a major pain. And I am not even talking about the GPU… Apple doesn’t even want to provide Vulkan drivers in macOS and you expect them to write both the Vulkan and DX driver stack for Windows?
Then again, in your later post you say that you think Apple will be willing to provide the drivers. I do not see any grounds for such optimism, but hey, your beliefs are your own. Since it is not a technical or business discussion anymore, we can only respectfully agree to disagree.
Could you be so kind to point me to where you think I say something like that? Probably poor choices of words from my side or some other kind of misunderstanding.
Well, again, I linked a video where he directly says that they are not considering direct boot. If you insist on putting more weight on some text written by third party than actual recording of the person saying things out loud, well, that’s your business.
I don't think Linux can be compared to Windows. There was never an Apple bootcamp solution for Linux even with Intel. The rest is, as I said, speculation, on your part and on my part, based on the little information available from their senior executives, on what Apple would do if Microsoft decided that Windows on Arm running on AS was a good idea. Which is quite unlikely anyway, so chances of this ever happing are close to zero regardless.
Appreciate that we can respectfully disagree (respect is not always what happens here on Macrumors, or anywhere else on the Internet, when someone has a different view). Concerning you question here is what you said earlier:
"So let's just focus on realistic solutions that will work just as well — virtualisation. Want to play games or running demanding Windows-only software on ARM Macs? Push Microsoft to improve their Windows on ARM subsystem, adding support for proprietary M1 x86 emulation features and push Apple to add low-level compatibility features to Metal that would make DX12/Vulkan emulation easier. These things are much more feasible than expecting them to develop and maintain a full driver stack."
All thigs I agree with by the way, other than the use of the word subsystem.
And yet Linux runs just fine on Intel Macs. Why? Because an Intel Mac is an x86 OC and as such mostly compatible with a x86 OS out of the box.
I think it is important to distinguish between the technical hurdles and political ones. It is clear that any relevant technical barrier can be surmounted if the will is there. But the amount of will also depends on the degree of the technical difficulty. Bootcamp is a great illustration. Intel Macs already are compatible with Windows, with third-party drivers readily available. All Apple needed to do is patch some things in the EFI, provide a basic driver or two for some of their proprietary components and write a pretty tool that does unassisted Windows installation. None of these things are expensive to do. Apple Silicon is a whole different story.
Thanks, yeah, I agree it’s a poor choice of words. “Fork” or “version” would be more appropriate.
Agree that it's a trade-off between technical difficulty and political will... And we are all guessing how much is one and the other, with somewhat different opinions. In the end however, Microsoft's political will is probably the biggest hurdle, so as I have said, bootcamp is very unlikely anyway, which means that virtualization is the way to go for Windows on Mac (with some emulation from third parties too).
Actually being able to run some Windows apps on Mac would make the transition to Mac easier for some people. Such as those relying on an older version of QuickBooks, but want a mac. They can get a mac and keep using that version of QuickBooks then when they finally need to move from it they can get a Mac replacement. Or people that NEED Microsoft Access for some things.
'These systems are engineered to run macOS, and make no explicit concessions for supporting other OSes; the ability to boot custom kernels can be viewed as official support for self-compiled builds of the macOS kernel, and non-macOS OSes need to behave like macOS does as far as their interactions with the rest of the platform. In other words, the ABI specification for every aspect of boot and firmware interaction is "whatever macOS does".'
Take a look at https://github.com/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon especially the Boot Flow part. It seems to me that the boot process of Apple Silicon has many similarities to iOS.
Oh, I fully agree. That’s what VMs are for. And it is indeed only up to Microsoft to officially support Windows virtualization on M1, all the technical issues have been solved.
Craig Federeighi sayed "we are not direct booting any alternate operating systems". that means no support for Bootcamp. He goes on to say that they see the future to be hypervisor VMs. They have obviously decided that the benefit does not justify the work. He has also been clear that those VMs would be ARM VMs and they don't see x86/AMD emulation as a viable route for them.
I think if Macs were Apple’s only product, supporting Windows apps on the Mac might make more sense. However, Apple’s success is due in part because they concentrate on how all their products can work together, so focusing (software and hardware) engineering efforts on their own products’ interoperability with each other will always be prioritized over supporting a competitor’s ecosystem.
Probably because Apple has indicated that they do not plan to do any support for direct booting of alternate OSs. Craig Federeighi says that the way forward for those OSs is through hypervisor VMs.
What would be useful is to have x86 emulator for M1 Macs. Just to run emulator, install normal x86 windows and use as normal PC (just a bit slower), in a window or full screen.
In another video he had said that running Windows on AS is up to Microsoft, they have the technology necessary for it. But whatever, all this does not matter since Microsoft is not interested and will probably never support licencing WoA on Parallels either. So end of the story for those hoping to run Windows 100% officially.