7 ms·
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 "
by foo92691 4y ago
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"?
- brundolf 4y agoMy 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
- Arnavion 4y agoYes, 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.
- oneplane 4y agoWindows 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).
- Arnavion 4y agoHaha, yes, I completely forgot about PocketPC.
- TheNewsIsHere 4y agoIt 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.
- gjsman-1000 4y agoWe 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.
- twoodfin 4y agoHowever, 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. That would still leave room for Project Volterra.
- johnwalkr 4y agoI 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.
- gjsman-1000 4y agoWell, 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.
- sgjohnson 4y ago> Microsoft could send a legal letter at any time. If the author doesn't distribute any Microsoft IP, there's nothing Microsoft can do.
- gjsman-1000 4y ago"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.
- dboreham 4y agoWindows (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).
- roblabla 4y agoThat'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.
- mlyle 4y ago> 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.
- AshamedCaptain 4y agoActually 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.