I'm a bit shocked that it would even be possible for a third party to implement such a thing without rebuilding Windows itself. Is it a matter of implementing "device drivers"?
The thing is, AFAIK, how to talk to the interrupt controller isn't part of the drivers, but part of the kernel. So you can't just "write a driver" for it. So if Windows doesn't support apple's interrupt controllers, I guess a lot of shenanigans will be needed.
He's planning on a thin hypervisor layer to map GIC to AIC.
As the OP said, all of this is abstracted by the Windows HAL, so it's just a matter of replacing the HAL (a separate binary). The problem is that the HAL is closed source. Outside of simple binary patches, I don't think anyone has come close to writing a new one.
This merger of the kernel and HAL invariably means patching the HAL is now equivalent to patching the kernel
Were there x86 but non-IBM compatible models or did you mean the alternate instruction sets (Alpha, PPC, RISC)?
What about ReactOS, do they use a HAL implementation or not?
Despite the benefits ARM provides amd64 undeniably has advantages and non-trivial ones at that.
personally, I'm of the opinion it'll come to a coexistence for a time rather than one dominating the other immediately.
Anyway, both amd64 and Aarch64 are already being used outside of Macs/Apple products.
Most manufacturers take standardized IP and IP-providers provide an appropriate linux drivers. Few manufacturers are willing to develop and maintain their own GIC hardware and GIC driver, most of the time they just take the ARM standard GIC.
The fact that Apple does not provide drivers is a consequence of the Apple business model. And the fact that the ARM ISA does not stipulate a unique GIC is actually a strength. It makes the architecture more versatile and suitable for evolution (maybe Apple found out that the ARM standard GIC is not complete enough for them).
We have plenty of examples in the wild. Just look at the state of Pine64 and u-boot, for example. It's a mess of standards.
And what you see as a strength others don't.
It seems pretty standard to me, not a custom GIC as Apple.
And yes, in u-boot there are plenty of device-trees for each target. What's wrong with that?
The device tree is usually provided by the manufacturer, the compiled device tree is usually very small and allows genericity.
“There’s an somewhat obscure feature on M1 (and M1 Pro/Max/Ultra, henceforth referred to as M1 v2) chips where part of the GICv3 can be virtualized to guest OSes to enable faster interrupt handling.”
Seemingly implementing it in a hypervisor?
To illustrate the issue with a silly example, imagine the Windows kernel assumes that every interrupt controller speaks Spanish, but suddenly AIC comes along and speaks Portuguese. The driver is going to have a hard time communicating.
A sibling commenter, gjsman-1000, explains that the idea is apparently to instead have a very lightweight hypervisor that actually presents a GIC to Windows, instead of trying to add an AIC driver, which might also have needed further kernel changes if Windows even has the concept of interrupt controller support being abstracted away enough to support interrupt controller "drivers" in its HAL. (I am not a Windows person at all, I don't know.) Basically not only having someone in between that seamlessly translates between Portuguese and Spanish, but actually pretending to be the interrupt controller itself.
However, they actually address this with the "What makes Windows on M1 hard?" area and talk about using a vGIC to do an extremely lightweight pseudo-hypervisor as a workaround. An interesting theory.
The main issue though is that Windows for ARM isn't for sale and can't be legally purchased outside of buying a WoA device. Microsoft could send a legal letter at any time.
If the author doesn't distribute any Microsoft IP, there's nothing Microsoft can do.
Only in theory. Microsoft could allege DMCA violations, or any number of threats. They might not have merit but they are still scary and could shut down the project regardless.
Windows on ARM isn't new. The oldest Windows on ARM was Windows 8 RT (ARM32 only, I believe). Right now it seems Windows 10 and Windows 11 have ARM64 versions, but there was also Windows IoT Core from the Windows IoT OS branch a few years ago.
If I recall (grain of salt then) a while after the first M1 Mac came out one of Apple’s VPs had said something on the record about Apple having tried to get Microsoft to sell retail licenses of a Windows 10 for ARM build, because they didn’t want to deprecate Boot Camp for Windows. But Microsoft said no.
However, just two weeks ago Microsoft announced their "Project Volterra" Mac mini clone for Windows on ARM development, which makes it seem mighty certain that Windows on ARM for Mac is not coming anytime soon because otherwise why on earth would anyone buy that thing...
On the other hand, if Project Volterra doesn't sell very well and Windows on ARM continues to flounder, maybe Microsoft will finally make Windows on ARM for Mac a real option in the hopes of capturing mindshare and gathering interest from all the people with Macs.
Reading the tea leaves, if Windows were to come to Apple silicon Macs in an Apple-Microsoft mutually supported form, it would almost certainly be as a guest VM under the macOS hypervisor rather than as Boot Camp 2.0.
That would still leave room for Project Volterra.
Microsoft does not sell retail licenses of Windows for ARM devices and what Apple proposed isn't the way Microsoft currently does business for ARM hardware.
Yes, Microsoft could change how they do business to accommodate, but so too could Apple.
If Microsoft turn around and ask Apple to license Windows and provide the OS as an option to buyers, or ask Apple to supply Macbook hardware so Microsoft could sell Macbooks with Windows on it, Apple likely would have said no too.
Maybe Apple can offer to run Windows on iPad? No...?
I agree with you.
Not quite. The Craig Federighi quote is:
>As for Windows running natively on the machine, “that’s really up to Microsoft,” he said. “We have the core technologies for them to do that, to run their ARM version of Windows, which in turn of course supports x86 user mode applications. But that’s a decision Microsoft has to make, to bring to license that technology for users to run on these Macs. But the Macs are certainly very capable of it.”
https://arstechnica.com/gadgets/2020/11/we-are-giddy-intervi...
The scuttlebutt says that Microsoft is locked into a requirement to only run Windows ARM on Qualcomm chips for an unknown period of time, although I've never seen anything from Microsoft to confirm that.
They're a ferocious company when it comes to legal.
That boat already sailed over a year ago.
>How did Microsoft screw this up? - Surface Pro X (SQ2) vs M1 Macbook Air