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"?
Windows (really: NT) has always been hardware independent. So it's a matter of a) having binaries and a HAL (Hardware Abstraction Layer) for aarm64 (this exists -- Microsoft already sells arm-based devices such as the Surface Pro X), and b) having the necessary set of device drivers. These may exit already from MS, or may need to be compiled from source already used for x86, or may need to be written from scratch if no driver exists already. But you definitely don't need to build Windows in order to port it to new hardware, unless it's using an unsupported CPU (and then you'll have much bigger problems than just building it).
That's only true up to a certain point. ARM is a very weird target, because a lot of standardized stuff we take for granted in x86/PC land aren't standardized on ARM. In particular, take the Interrupt Controller: x86 has a standard for it (well, technically has two, the PIC and APIC). The "standard" in ARM-land is the GICv3 or GICv4, but many different CPU vendors have their own. Apple has the "Apple Interrupt Controller", or AIC.
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.
Actually you might be surprised. Windows NT is _older_ than many of the "standards we take for granted in x86/PC land", and for example it does support multiple types of pre-ACPI ways of bringing up multiprocessor systems and specifically multiple types of interrupt controllers. Heck, x86 Windows even supports non-PC servers from Compaq and others; ever tried to press F5 during (old) Windows NT setup ?
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.
Generally speaking part of the issue with a custom HAL nowadays is that Microsoft moved the HAL from being a DLL to being a statically linked library within the kernel (likely as a performance optimization and because there's no real need for a new HAL in most instances when HAL Extensions exist)
This merger of the kernel and HAL invariably means patching the HAL is now equivalent to patching the kernel
Not GP. I'm not sure if there's a special Compaq version but there's a version (until Windows 2000, https://winworldpc.com/download/5204c39d-c3a9-5a68-11c3-a7c2...) for NEC PC-98 architecture which is x86-based but IBM PC-incompatible, so it's likely that a Compaq version exists.
> 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.
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).
The mistakes are already happening. There are RISC-V processors being shipped with unfinished extensions and weird MMUs and now Linux has to decide whether to support those or only support finished standards
The author plans on using this feature to help bridge the interrupt controller:
“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.”
You also have to have the abstractions and hooks at the right places, though. Linux had that problem: The AIC (interrupt controller) is sufficiently different from the standard ARM GIC that ARMv8 Linux had to receive more fundamental patches before AIC support could be cleanly added.
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.
Well, if you ask the Asahi Linux team, heck no this isn't possible. Windows doesn't understand the Apple Interrupt Controller and a driver (at least in theory) should not be able to fix that without major kernel changes.
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.
My understanding is that drivers aren't part of the kernel in Windows like they are in Linux. And I believe an ARM build of some kind or another already exists out there for Windows
It does. Officially there is an ARM build of Windows that Microsoft licenses to OEMs, and there is (or maybe was?) Windows IoT Core which has a build for ARM.
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.
>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
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.”
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.
My own pet theory, based on absolutely no inside knowledge, is that MS doesn’t want to have Windows on M1+ until other CPU makers have caught up to Apple. It would be a huge embarrassment to have Apple hardware running Windows that much better than all the native PCs. All the PC OEMs would slash Nadella’s tires.
I like the theory, but I’ll counter with my own theory that MacBook Pros were the best Windows laptop for many years, and they ended up pushing PC quality to catch up which was good for the Windows install base and Office. :)
Pretty surprising that MSFT would end up with a deal like that, I'd feel like they would be in a position of strength. Unless all the ARM vendors were pretty supicious of whether Microsoft would succeed/invest properly in the ecosystem?
We learned last November that Qualcomm had an exclusivity agreement for Windows on ARM that lasted a (speculated) 5 years... which they then did almost absolutely nothing worthwhile with. As of November it was "expiring soon" but what "soon" means is still not clear. Perhaps it was renewed.
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.
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…
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.
I don't remember that, but Apple have actively made changes to support Asahi Linux (I wouldn't go so far as to say they support Asahi Linux) and not backtracked on not-blocking other OSs.
It seem a bit disingenuous for Apple to shift blames to Microsoft.
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.
Yes, there is a public stable API for Windows drivers. Even the built-in drivers are dynamically loaded.
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.
Windows CE on ARM and Windows PocketPC on ARM is older than that. But all of it has the same issue: you nearly always need a specific rebuild for a different ARM-machine because there isn't a single "ARM PC". Just like x86 pre-ACPI where you need different HALs and bringups for different systems. The problem here is twofold: firstly windows is closed so you can't actually add/modify components and rebuild it, only binary hacks and additive installation (like driver packages). Second issue: licensing. ARM isn't available unless you are an OEM. So there is no legal way to run Windows on M1 unless you are Apple and Microsoft signs you a contract (and that hasn't happened either).