hey, OP here, figured i'd clarify some things about this project:
1) yes, I realize this is going to be way harder than it seems, but I'm actually going to do my best to hopefully get a good user experience out of this and I'm easily preparing for this to be a multi-year effort, but I'm not going to give up right at the gate
2) Custom HALs were actually an option, up until very recently, since as of Windows 10, version 2004, the HAL is now statically linked into the kernel, meaning that if I wanted to use the AIC natively I'd need to write a patch finder that runs before the Windows kernel loads (This is what EfiGuard does for example to disable PatchGuard)
(Yes this is actually more tenable than it may seem, due to some undocumented policy files Windows is able to use, but I have already decided to hold off on this until after I get Windows working under the thin hypervisor)
3) HAL Extensions (for those unaware they are tiny modules that allow you to extend the Windows HAL with functions for non standard hardware) are not tenable at the moment since they're limited in the APIs they use
4) I am well aware that Windows is going to need a lot more help than just purely the interrupt controller, I'm currently trying to bring up the vGIC first since the distributor and redistributors need to be emulated and I need to bring up Project Mu first
5) as for the GPU, I'm way too far away from that being a concern to figure out the approach lol
if you have any feedback btw, please do feel free to comment it i'll try to address it as best as I can
yes I'll update the website theme soon enough, thanks to the commenter who remarked about readability.
May I suggest you don't license the work in a way that allows it to be commercialized without your explicit permission and handsome compensation to you and any other contributors. You'll need this to be sustainable and it'll be incredibly frustrating if a company de-facto hijacks the development and takes it in a direction you don't expect or want.
Oh but then half of HN will complain about how that's not truly open according to a dictionary definition thus automatically becomes untrustworthy and they won't touch it with a ten foot pole. (/s)
Jokes aside, technically I don't disagree on the "dictionary definition" thing there... but it's interesting how the current landscape has shifted and now more control for the developer starts to become a common interest between "hackers".
The original OSS licenses protected users (as in, final users) from predatory devs; nowadays, small devs and hackers talk in their forums about how to preemptively protect themselves against predatory users (as in, not final users, but other bigger devs that leech on other's work)
It doesn't look like we can say "licenses like AGPL". It's more that AGPL is basically the only one in that vein. Remove the A, if you please, but that's pretty much it in terms of variety.
On the other hand, reading HN over time I also got the idea that *GPL has been tried with the intention of avoiding abuse, and it failed several of those intentions. I now regret not having taken note each time I saw comments in that regard, for quick references.
But there are big cases, not only small comments spread over HN; I guess the stereotypical one is MongoDB, which tried the AGPL path and in the end was not satisfactory enough for them.
The problem is not with the GPL. The GPL is just as enforceable as any other proprietary license. The difference is that these amateur projects often don't have the resources to fight infringement.
I was addressing what seems to be an unfair criticism of the GPL, and not claiming that the license would help. In fact your comment reinforces the point - even a proprietary license wouldn't help with no legal backing.
You have a legal leg to stand on that some lawyer might potentially fight for you, that's still better than just giving up and surrendering your weapons.
You cannot have a "fully open" license which disallows commercial usage. Both the OSI and FSF definitions of "open source" and "free software" licenses would exclude such a license. Of course you can create a proprietary license which disallows commercial usage, but it won't be "fully open".
FSF-compatible licenses absolutely can exclude commercial usage, and software can be made simultaneously available under a separate (paid) commercial license if the authors wish. It's only the OSI that doesn't allow this.
> FSF-compatible licenses absolutely can exclude commercial usage
Can they? The FSF seems pretty strict on saying that commercial usage cannot be excluded.
> “Free software” does not mean “noncommercial.” On the contrary, a free program must be available for commercial use, commercial development, and commercial distribution. This policy is of fundamental importance—without this, free software could not achieve its aims.
> FSF-compatible licenses absolutely can exclude commercial usage
No, they can't, use-restricted licenses are non-free, by the FSF definition.
> software can be made simultaneously available under a separate (paid) commercial license if the authors wish.
This is true, but the Free license cannot be use-restricted, or it ceases to be a Free license (if the copyright owner, owing no obligation to any upstream licensor, does it, they could add the use restriction to a Free license, but it would by that act cease to be a free license; that violates Freedom 0.)
Hence the full circle to my original sarcastic joke. The OS definition serves a purpose of protecting users, even the bad ones, and maybe that worked when the "bad ones" where a minority with small impact.
But nowadays things have changed. The "bad ones" are big fish, and have enormous impact. A growing subset of devs now start looking elsewhere, and a plethora of non-OS licenses start to pop out. People still want to give their work for free, as long as it is not going to help someone else get rich while the original author doesn't see a cent.
One day, maybe, some organization will study the current landscape, and write a new set of definitions that are able to catch the spirit of this new situation. I guess it's just a natural part of how things evolve.
There is the Ethical Source movement, that aims to prevent use of software by bad people. The FLOSS community doesn't even have resources enough to enforce the widespread violations of copyleft licenses, so it seems even more unlikely that Ethical Source folks will be able to enforce their licenses. There are lots of other reasons for the FLOSS approach too.
It didn't really come across as a joke despite the /s, it seemed like an earnestly held opinion that is, TBH quite reasonable, although it isn't something I would agree with.
Read history guys. I even did a master thesis cf the two. The open source is against the free source by deliberating allow commerical software. Down vote you may, you cannot change the history. In fact learn seriously about that part, otherwise you miss the whole point of open source.
Well, whilst down voted let me repeat the thing - some Vp did not invent internet but he did let go of only education institute used that network. Now it allows commercial activities.
The mix is hard. The pure is ease. But without the mix and the complexity dealing with this, you do not have today open word of software and even internet.
And mix is hard. (And pure like free source is so pure it is a cult those days.)
I don't generally like restrictive licenses but in this case we're taking about running closed, commercial software on closed, commercial hardware. It makes sense to use a GPL to prevent one of those companies from taking all of that hard work and incorporating it back into their platforms for free.
Mine was just a lighthearted reflection on the issue, but in general I'm supportive of the copyleft ethos. And yes, in this case it would make a lot of sense.
Actually my first reaction was to think, "Why are Microsoft themselves not doing this job?"
I'll definitely take this into account thanks for bringing it up! Licensing is something I've thought about a bit before starting, right now since m1n1 (the hypervisor I'm iterating on) is MIT licensed for the most part, I'm inheriting that license too for my fork of m1n1 (i'll mainline the changes btw! need to work with marcan once they're done), but as the project goes further I'll definitely consider the question of licensing again.
It'll just be sad to see apps like VMware or Parallels release a new version claiming they made a breakthrough after you've made some milestone release...
IANAL but I'd like a license that goes something like this:
Companies: If you are working for a company/corporation/profit-generating entity, or otherwise intend to sell or use such code derived from this repository for profit-generating purposes, you shall not be permitted to use any of the source code herein until you email me (author email here) and we can come up with the appropriate terms and conditions for your use case.
Everyone else: Have fun!
Obviously it's missing some necessary edge cases and disclaimers, but yeah.
I mean, that's basically what CC-BY-NC is. Any licence that prohibits commercial use does not prohibit an alternative commercial licence being negotiated.
> PolyForm is a project to draft and make freely available plain-language source code licenses with limited rights.
>
> Source code licenses with limited rights? What does that mean?
Many software developers want to make software available under source code licenses that grant some, but not all rights. Some licenses that have been released before include the Commons Clause, Elastic and Confluent licenses, and others. These licenses grant broad rights, including source code access, but reserve some rights to the licensor.
To be clear I'm not just trying to be a pedant and poke holes in your legalese here. I'm trying to show that it is genuinely hard to draw a line between what kinds of profit seeking are morally acceptable and what are not. People generally deserve to seek out prosperity, and I suspect in most cases trying to differentiate between these cases will end up being a game of "people richer than me have to pay, people poorer get it for free" which is way less morally justified than the current situation with software licenses.
> I have already delegated this to after I get Windows working under the thin hypervisor
Not to be 'that guy', but that's an odd use of of the word 'delegated'. 'Relegated' might have been the word for which you were looking.
Edit: I know this will be down voted because I'm critiquing the word usage of OP instead of focusing on how cool their project is. I get that. I'm just pedantic and this sort of thing eats me alive.
Personally, I've learned to talk more precisely from these sorts of comments than anywhere else. In real life, people will rarely correct you. I think the concept of a "meta comment" is interesting, where you could push this sort of thing into a separate parallel thread that would normally be hidden.
That's an interesting point. It's much easier to correct a stranger on the Internet, but it's also harder to be kind. Comments that manage to do both (like GP) are great, and I always like to see them.
> 3) HAL Extensions (for those unaware they are tiny modules that allow you to extend the Windows HAL with functions for non standard hardware) are not tenable at the moment since they're limited in the APIs they use
I haven't heard of those before, and I'm fascinated by them. I go looking for documentation – and I can't find any on Microsoft's website – some documentation which mentions their existence, [0] but no details on the API or how to write them.
Is this something you have to sign an NDA with Microsoft to get access to the headers and docs for it? Or will I find the headers hidden away in the WDK somewhere?
Is there any good public source of info on them? The best I've found is [1] – which includes some important details but isn't comprehensive (not that anyone would expect a slide deck to be).
> Is this something you have to sign an NDA with Microsoft to get access to the headers and docs for it? Or will I find the headers hidden away in the WDK somewhere?
Turns out the header file is included in the Windows 10 SDK, as km/nthalext.h
(You can download the multi-gigabyte Windows 10/11/2022 SDKs to get a more recent one, although not sure if anything has changed.)
Still doesn't seem to be any public documentation. The header includes very detailed comments, but (as you'd expect for header file comments) they concentrate on the nitty-gritty and omit the big picture.
I’m interested in Windows VMs that have minimal overhead/maximum speed. As far as I understand that’s done by it being installed as native to the hardware as the native OS, but with generic drivers. Roughly what % of the work for running Windows on M1 is running Windows in a VM on M1?
Good luck, I hope it works out. It is hard to be in between two of the largest and most established tech companies in the world. If Apple or Microsoft wanted it, they could make it happen. I assume neither want it, at least not right now, so it is clearly an uphill battle.
I was just really curious what your motivation for this project is. Just an interesting technical challenge? I'm impressed at anyone taking on something that is just so obviously ...difficult.
And don't you worry that if you succeed, either Apple or Microsoft will make some small change to kill it?
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).
Why would Apple want to make it hard to run aarch64 Windows on an M1 device? Their support for Windows in Boot Camp drove a lot of sales of Mac hardware after the switch to Intel. Seems Apple is limiting their hardware sales to not support Windows on M-series Macs.
(Then again, if they are having supply/capacity issues then maybe it's a matter it being on the roadmap but they want their hardware running macOS until that demand is fully met?)
Apple has stated that they won't stand in the way of Microsoft porting Windows to M1 Macs[0], and indeed M-series Macs have the bits needed to boot alternative operating systems that M-series iDevices lack. Currently Microsoft only licenses Windows for ARM to device makers (and potentially has an exclusivity agreement with Qualcomm[1]) and has stated that they don't support Windows on M-series. The ball in is Microsoft's court on this one.
Currently Microsoft only licenses Windows for ARM to device makers
Apple is a device maker. I wonder if Apple could buy a license from Microsoft.
I'd like to see either Apple or Microsoft officially support Windows on the M-series machines. Not because I give fig one about Windows. But I'd like to see the chaos that follows.
The operating systems industry could use a bit of a shake up.
I would guess that this scenario is unlikely at best. Even if Apple expressed interest in purchasing a license, Microsoft would likely not sell one to them because their primary interest in licensing Windows is getting devices to ship with Windows preinstalled, and Apple is most certainly not ever going to do that.
> The operating systems industry could use a bit of a shake up.
There is no OS industry anymore. What's left is OS's that ship telemetry and ads to customers (both Apple and MS do this). Linux-based OS's made a lot of progress, but still they're not ready for mass adoption.
I don't have the impression that they're doing anything specifically to make it hard. But right now users would have to pirate Windows in order to run it on Apple Silicon hardware, so it's hard to argue for an official solution. And they're not currently publishing specs in the open that would really speed it along.
But the Asahi Linux developers say Apple is helping in some measure[1], so it doesn't seem likely that they're hostile to running Windows on these devices.
You don't have to pirate windows, you have to buy Parallels, which then downloads and installs Arm windows onto your M1 - and Arm Windows will run x86 binaries.
I used this to run FPGA bitstream-creation software on my Mac Studio. Worked like a dream. I'm generally fine with running on the PC on the bookshelf and serving s/w via MS Remote Desktop, but having it on the machine itself is a bit more useful in terms of screen real-estate (3x 4K monitors on the Mac).
It's technically pirating because the license of Windows for ARM does not allow end users to run it on arbitrary hardware or virtualize it. I have doubts that they'd ever actually enforce those terms though.
>the license of Windows for ARM does not allow end users to run it on arbitrary hardware
Microsoft does not agree:
>Yes customers can use retail copies to run Windows 10/11 on Macs, including ARM Macs. The Windows retail EULA does not have any use rights restrictions on the type of device you install Windows on.
It is a problem for businesses though. If they were going to go after anyone, it would be a business violating the EULA. Same problem with running macOS on Windows.
This isn't quite the intent of the project here, though, which aims to run the ARM build of Windows as close to the hardware as possible. Not through a VM running inside macOS, but rather under a lightweight hypervisor running on the bare metal.
You might not have to pirate Windows to do this, but I feel the rest of your comment is missing the mark.
Parallels uses Insider builds of Windows ARM, which aren't useful if you want a stable system. Additionally, Microsoft only offers those builds for people who have Windows ARM licenses, so you can't use this in a professional setting since you're violating the EULA.
The current version of Parallels uses the stable build of Windows 11 for ARM.
Once you've installed Windows, it's possible to pay for and license Windows directly from Microsoft via the Windows Store app. There might be a brief period where you're technically unlicensed (not sure what the exact verbiage is in the current Windows EULA about trial/grace periods), but the end result is a properly-licensed Windows 11 install.
Parallels in operating in a legal gray area and using Insider builds of Windows on ARM that are not licensed for M1 hardware. There is currently no legal way, from a licensing standpoint, to have an ARM build running on a device that Microsoft does not have an existing agreement with.
If you're running an M1 with Parallels in any type of business or money-making environment then you're putting yourself at risk.
> There is currently no legal way, from a licensing standpoint, to have an ARM build running on a device that Microsoft does not have an existing agreement with.
That appears to be incorrect[0]:
> Fortunately, they had something to share later, again through an official Microsoft spokesperson (that faceless PR-driven process where press or analysts can ask Microsoft for an official response to a question). A lengthy Twitter thread on the topic[1] (driven by a new ARM64-based mini-desktop computer that ships with Windows 11 but without a license — until that was changed by the manufacturer of the device to say that it did indeed include a license) pointed to a blog post from Wes Miller[2], an analyst and licensing expert with Directions on Microsoft[3]. That post included this quote:
>> Yes customers can use retail copies to run Windows 10/11 on Macs, including ARM Macs. The Windows retail EULA does not have any use rights restrictions on the type of device you install Windows on. Note that the EULA does stipulate that not all versions of Windows are supported on all device types, so theoretically customers could run into compatibility issues with performance & support case by case, but this is not a licensing restriction. Customers can find more details on compatibility at https://aka.ms/minhw.
What's the basis for this view? Microsoft will happily sell me a license key for Windows 11, will let me download a Windows arm64 build and activate it, with the license explicitly stating that installation on a single virtual machine is permitted, and with no apparent restrictions on the hardware which can be used.
It's totally possible that I'm just missing something but I don't really see what it is – as far as I can tell I purchased and activated a copy of Windows 11 21H2 directly from Microsoft.
I don’t get it. Microsoft just refuses to license windows on ARM to end users.
There’s a VS community post about it, and I think there must be some denial or something going on. Lots of deliberately obtuse thinking and circular reasoning for why this can never ever happen, despite 100,000 Parallels users demonstrating that it works.
Apple is in a very different position than they were with the switch to Intel. Some versions of Microsoft Office lack "legacy" features like Excel macros [1] and collaborative editing [2]. Microsoft would love to run Office inside a version of Windows on the Mac, as part of an on-ramp to people buying Surface-branded hardware. Apple isn't going to be an euthastic provider of this.
[1] Works-ish on Mac, not at all on iPhone.
[2] Collaborative editing on the Mac version works until you point at a file hosted on an on-premise Sharepoint instance, then it's Windows only.
I'm confused by this comment. Apple seems to be fine with Windows running on M1, it's MS that doesn't provide licenses, although they do provide easy access to software images. And anecdotally, I can say that x86 windows apps running on ARM windows running on Parallels on an M1 mac works fine for the most part. And on my mac/in my org, collaborative features of Office (both in-browser and in-app) work equally well in Windows and MacOS.
Who says Apple wants to make it hard? Not prioritizing making it not hard probably is enough to make it hard for those outside of Apple (and “not prioritizing” probably comes about because they don’t see many people running essential software on aarch64 Windows that doesn’t run on Apple hardware, or has equivalent tools on Apple hardware)
They're not making it hard but they are definitely not wanting to expose any details of their implementation of aarch64 to any would-be ARM hardware competitors.
They have about a 3 year lead as I see it on performance/watt.
Why would Apple want to go out of their way to make it easy to run Windows on an M1 device? Maybe they just developed the platform to run the intended target OS, and didn't bother to include features that weren't necessary to meet that goal.
I am struggling to see here how this shouldn't be something that Microsoft does itself. And, if Microsoft is doing it, they can just call Apple and get what they need re: documentation or specs or questions answered. They might just need appropriate NDAs between the two companies (which I'd have to imagine they already have?)?
With Linux they have to reverse-engineer it. Microsoft shouldn't need to...
The current rumor is that Apple is open to Microsoft doing it, and that Microsoft has an exclusive license with Qualcomm for ARM windows. This license expires soon.
> "that's really up to Microsoft," [Craig Federighi] 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."
Actually - come to think of it there is one reason. If this person wants a job with Microsoft or Apple getting something like this working without the support of MS or Apple is a hell of an exceptional application...
I’d frankly be surprised if you were able to muster the talent/willpower for something like this.
1. Most of the people able to do this sort of thing probably work in Linux/FreeBSD/etc land.
2. You’re really working doubly against the tide here. You have proprietary stuff on the Mac and on the Windows side.
3. (Personal opinion) Dear God that sounds like a lot of work for something that is a fairly unfriendly experience on a few levels.
At least they have Linux/BSD people trailblazing here (they acknowledge as much).
If they can actually pull this off without changing something deeper than a what’s already exposed to kernel driver developers without horrible hacks or inefficiencies, I would be surprised.
I feel like there should be a common etiquette rule on HN where if you don't care about a particular project / technology / initiative that you skip commenting and move on. For example, your comment says that this initiative will not work out. Should there be a debate whether or not it's theoretically possibly for this to work out logistically? What is the value in that? Even if there is a convincing argument that this initiative could theoretically be successful, would that convince anyone to use the technology? No, it would not.
I would be with you except for the "Disclaimer: Not really a kernel dev of any sort." bit at the end. Skepticism from people not in the field is far less meaningful (as is booster-ism, for that matter).
You’ll only know by doing it. It is especially blind because, as you say, it’s bringing two black boxes together. It’s a sufficiently major point of interest to such a large number of people that I hope people feel motivated to try.
I feel that this is "rule" would be either incredibly harmful or effectively empty.
The post you are criticizing is quite obviously not an example of "don't care", nor is your "summary" anywhere close to accurate. Yet you want to remove such posts? Do you want to remove all constructive criticism or debate while you are at it? Only echo chambers allowed?
hey, I'm the person embarking on the project, thanks for checking it out!
one of the big reasons I started this project is that I've really been wanting to work on a project that deals with bootloader and kernel level code, and doing Windows bringup on the M1 seemed like a really interesting thing to tackle.
While initial progress might be slow, it is indeed happening, I'm planning to post an update tonight actually, but I realize you're busy so feel free to check the website whenever you have a free moment. (It's basic I know i'm not a web person lol)
Unfortunately, I was born little after NT was already introduced :)
It indeed is really an impressive feat of engineering, but really almost all existing OS platforms are essentially from pre-2000s. Even fushcia's magenta (iirc LK was inspired by BeOS, the author worked at Danger prior).
Next Steps: Get the Windows GUI + Win32 APIs + backwards compatibility layer to run on WSL2. Port the best parts of NT to the Linux kernel.
Final Step: Replace NT+WSL2, with the Linux kernel. Use the current devs/tests/etc working on NT for better ROI (from a business customer perspective the NT kernel is no longer a positive differentiation).
I know where you’re coming from, but the reality is MSFT no longer has that ability.
1. Desktop/laptop OS based revenue is in decline. There is no reason for it to go up again. Between Chromebooks on the cheap end, MacBooks on the expensive end, and iOS and Android supporting an increasing number of productivity and content creation apps “with a free OS”, there is not much room for new and soon old companies to pay for OS licenses (other than legacy custom code - being “actively” migrated to Azure).
2. Because of Azure competing with AWS and GCP with a Linux distribution, MSFT already has teams with Linux expertise and working on improvements. This can’t get “extinguished” people just migrate Linux workloads elsewhere.
This leaves us with:
> Wonder what would come next
Likely more improvements to the Linux kernel from MSFT. Maybe even a big push of Linux to Rust (with Amazon and Google as partners). A bigger push from MSFT to get hardware manufacturers to build open source drivers into the kernel directly (so MSFT doesn’t need to fund the work for each of them). Maybe even “Windows” over Wayland. Basically windows/linux rather than gnu/linux.
Likely more applications built on DirectX + Linux native (ie without Win32). Maybe even Office without Win32. A Windows compat layer for gtk or qt or Flutter or whatever is good at the time. Even if only for new application creation.
Likely, given the direction of gaming at MSFT, DirectX (or whatever they call it) competes with Unreal for cross platform game stuff. For the next big revenue stream for MSFT from game devs (including their internal studios).
Are those final two steps (next, final) pure speculation on your part? I'd be surprised if Windows threw out NT and moved to Linux kernel, and yet at the same time, it sounds like a great idea IMO (WSL2 + Docker is already a great experience for software development).
Not the parent commenter but this isn’t as far fetched as it seems. Since much is abstracted by the Win32 and other APIs, they could write something to do exactly this.
This seems unlikely to me. For example, the threading model (non-forking) and file system semantics (locking, permissions, etc.) are wildly different. You’d need a complex compatibility layer and effectively two classes of applications (legacy and linux-y).
If they can build WSL2, and WINE can be built without MSFTs help, I’m not sure what is left to doubt.
At that point the only question is “Is the one time cost of building the compat layer less than the ongoing cost of improving NT? Building windows specific drivers? Etc”. “One time cost” is always going to win the negotiation in the long run.
Surprised I had to scroll this far to see this. It's an objectively cool project, even if it doesn't make the most financial/business sense. Doesn't seem like that's the point.
I refuse to believe that there isn't at least one person or team at Microsoft looking at this already, so it's not only free work but may also be redundant.
Microsoft and Apple are traditional enemies. Microsoft has no reason to make Apple's hardware more attractive to customers.
The thing I don't get is why a consumer would want this. You want an _extremely expensive_ windows laptop. I guess the hope would be that the battery life is worlds better than anything you'd get in standard windows-land. But in reality battery life optimization requires paying careful to the devices and their drivers -- e.g. when parts of the system shut down because they're not in use. Not easy for a project like this.
So I'd sadly guess you end up with an expensive windows laptop with battery life comparable to a standard windows laptop. But you get that nice minimal Apple industrial design. :shrug:
Why would Microsoft not want this? They make money off of selling Windows licenses, not selling hardware (Yes, I'm aware the Surface exists). The more available hardware to install Windows etc on, the more $ Microsoft makes.
Balmer or not, Microsoft is still in direct competition with Apple for much of its core business. So encouraging customers to buy a laptop where they get $50 for the windows license and if they're lucky another $100 in software sales, but their key competitor gets >=$1000 of profit -- yeah, it's pretty clearly a bad business choice.
Just looked at the earnings report and I have to agree with you. Windows + Office was 25% of MS's revenue in 2021, but I suspect you're right that the big majority of that is not consumer-driven. FWIW just 2 years back, Windows + Office was 40% of revenue, so this segment is very rapidly becoming less important.
Making sure that windows works properly and keeping it working for however long they want to support it has got to cost a bunch of money. The question is, will they ever sell enough Windows licenses for M1(/2/3/etc.) Macs to make up for that investment, let alone profit?
TBH I have a hard time understanding why people choose to run windows at all, except for playing games. If you're stuck using windows because the corporate overlords insist, then yeah that sucks.
Also you can always run windows in a VM. Even on an M1.
Windows has fantastic accessibility properties/support. They even have a blind dev working on Visual Studio (or did)[0] for awhile. Apple's accessibility options are not anywhere near on-par with Windows. Linux ... I honestly haven't ever tried a screen reader in Linux and I have a feeling it is 100% up to whichever dev implemented something with no centralized style of doing things.
I’m with you.
Many people constantly complain about windows but most of them still using it. They say it’s going to get better, but it won’t. You could spend five years trying to make windows run ob an M1 und MS would break it within an hour.
I’m done with microsoft, they disappointed me to many times, never again. It’s necessary for some games but it’s getting better with linux (thanks to valve).
> TBH I have a hard time understanding why people choose to run windows at all
I use Windows and Linux equally as often, and I don't see this changing. There are some areas in which Windows itself is far superior, e.g:
- HiDPI and font rendering (ClearType is the best font AA solution I've ever seen);
- gaming and 3D graphics (Direct3D is a straightforward API to program with; OpenGL is 'deprecated', and Vulkan is a mess);
- multi-GPU support with Optimus and related switching technologies;
- a catch-all OS API to program with (WinAPI goes as far as handling user folders, libraries, application configuration and data[0], whereas on Linux land it's just a mess of hopefully-defined environment variables and if not, everything is dumped into a dotfile/dotdir);
- a nice shell[1] (IMO, superior to bash and friends) that is bundled with the OS to manage said OS, with object-oriented data throughput, strong(er) typing, and access to the .NET library;
- as of Windows 11, increasingly unifying UI/UX experience with WinUI 3 (yes, it was a mess with Windows 8 and 10; Vista and 7 were the most recent OSes to drastically change the 'desktop environment', and Windows 8 was a very mild reskin of Windows 7, all things considered);
- powerful ACL-based permissions model and 'hidden file' metadata bit, instead of expecting a dot prefix to mean 'hidden';
- a kernel structure that makes writing third-party device drivers straightforward, because there is no need to compile out-of-kernel drivers with headers;
- vastly improved touchpad handling compared to Linux (yes, OS X is better still, but given that it will be increasingly difficult to 'hackintosh' after Apple's move to ARM, this is a moot point);
Furthermore:
- there are some software that are either industry-standard, or superior to the competition that only run on Windows/OS X, or even only on Windows (e.g. MS Office, Adobe suite, Visual Studio, Autodesk Maya/CAD; Active Directory);
- there is less incentive to run Linux bare-metal when WSL2 exists;
- Windows still holds a supermajority of desktop users, and it would do well for developers to use the OS that their users use, aka dog-fooding.
I have never understood this hardcore anti-Windows dogma that so many hackers seem to have.
On top of that, you can run majority of mainstream Linux tools on Windows, natively, without WSL. Contrary is usually not the case, you need Wine or VM.
There is context for everything - Linux is great for servers and particularly IoT since you need lots of them, it doesn't make sense to pay for Windows Server in that case. Since Desktop can be used mostly free of charge nowdays, I don't really see a problem.
And ofc. PowerShell is light years better then anything on Linux, not that it is much important now since pwsh is cross-platform.
Fair counter-point, but that's a pretty different situation. I should have said "MS has no reason to make Apple's laptop hardware more attractive." In 2014 when Office was released for iPad, the Surface had negligible market share. Microsoft was losing badly in the tablet space, so they were trying to catch up any way they could. At the time it would have been reasonable to plan for a future where Microsoft completely lost to Apple in the tablet hardware space, so they needed to protect Office (critical line of business) from becoming irrelevant in what was clearly emerging as an important hardware category. Yes even then they weren't so arrogant as to try to protect the fledgling Surface business by withholding Office from iPad - a move they certainly had used in the past.
But today's laptop market is very different. Apple and Microsoft are still very much competing for dominance in laptops, which is an important source of revenue for both companies. It's a familiar pattern where Apple sells fewer units than many others, but at much higher profit margins. MS gets their tax from all these PC sales at high margin, but it's a small amount compared to Apple's huge hardware margins - and that's the key point why it's a bad idea. A consumer who buys a mac to run windows gives WAY more money to Apple than Microsoft.
The secondary point is that every Mac sold erodes the waning dominance of Windows, bleeding out Microsoft's cash cow. Nadella wants (NEEDS!) you to believe Microsoft is kinder & gentler because he knows the days of Windows' hegemony are behind us and there's no stopping its slow fade to irrelevance. That doesn't mean they want to it to happen. Directing consumer's money into Apple's coffers unquestionably accelerates Microsoft's problems.
I don't think Microsoft sees a future in Windows. Their current strategy seems to be one of extracting as much value from it as possible until it dies.
Really? I think Windows is in the best state it's ever been... WSL is incredibly nice to use as a development platform, and many well-designed apps have a Windows version ever since Electron started becoming the de facto standard.
Hmm, I guess you must mean that the native Windows development environment (i.e. .NET/Windows App SDK) isn't very developer friendly; I'm afraid I don't have any idea or how to compare it to Swift or Cocoa. As a user, though, I have better access to software and tools than ever before!
I can get Windows hardware for dirt cheap. Much cheaper than any Mac hardware. So if I am using the computer as essentially a dumb terminal to connect to a service over a network, there’s no reason to buy Mac hardware. Yes the hardware is janky and the OS is bad. But I’m getting what I pay for, and here my needs are modest, so why pay more?
Besides that, some people actually like Windows, or dislike Macs, though I’m not one of those people. I prefer the Mac. I just see when the Mac is a poor buy compared to Windows.
Those aren't the only two options. There's not really any such thing as "windows hardware" - and if you really want maximize performance of low-end hardware, Linux is really the king for that use-case.
A lot of low-end hardware will not even run Windows 11, which is probably going to be more and more of a pain to deal with as time goes on.
I have to run proprietary software on it. Installing it on Linux is a pain. It’s doable in Linux, but the hassle of Linux gets me absolutely nothing in return here. I’ve used Linux extensively so I know.
I don’t need to maximize the performance of the hardware. I don’t need Windows 11.
Use the web-based version in Edge. It’s not quite the desktop version, but it has improved a lot. At this point I’d rather use the web-versions of all office tools on a Mac rather than deal with installing them.
Microsoft’s MacBU has always been a separate team who I don’t think have ever held back on trying to make good products and have put surprising amounts of effort into it. Even the PC Office team doesn’t care if the Windows team does well, after all.
They do however have nightmarish build processes and technical debt that when I mention here get replies from people claiming I must have made it up.
Can you dual boot any other OS on ARM Macs yet? Seems like this project might have missed a few steps along the way.
This really should be a Microsoft effort. They just announced that they have Visual Studio compiling in ARM64 finally, so it's only a matter of time before the only thing standing in the way is backroom deals that we don't know about. Qualcomm?
I mean, I do want to see Qualcomm ship their M1 competitor, but given the state of the economy and world recession we're about to enter, I am skeptical it would survive fat trimming cuts that are about to sweep the industry. The money for them is in mobile and automotive projects.
Yes, https://asahilinux.org . I think this is coming at about the right stage in the game - the Asahi folks have figured out the baseline needs for booting another OS and have a basic bootstrap loader and hypervisor (m1n1) as mentioned in the M1 Windows writeup.
I think the OP writeup is fairly clear-eyed in terms of what needs doing - bring up the basic interrupt controller setup and IOMMU oddities needed to get UEFI and then the kernel to come up, and then start chipping away driver by driver until the system is usable.
This is basically what Asahi did and it's worked out well for them.
The Asahi folks are some of the best hackers I've talked to lol (project dev here) so definitely give their IRC a visit!
Fun side note I volunteered to help fix up the Apple silicon I2C driver to use interrupts instead of polling, so I'm definitely also trying to get more involved with Asahi too
Yes, the asahi linux people have had linux booting for quite awhile now. They're still working on all the drivers that you want for a good desktop operating system.
Haha as if microsoft couldn’t easily ship a build for apple silicon. The thing that makes this a difficult project is that MS doesn’t seem to want it to happen.
I would he surprised if someone at MS didn’t have a build that runs on m1
Trying to get an OS to work with proprietary undocumented hardware is not easy. Microsoft may have decided it’s not worth the effort.
Usually Microsoft gets the hardware manufacturer to make sure their hardware works with Windows. In this case Apple have probably decided that supporting Windows themselves is not worth the effort either.
Likely neither of them want to get into the support headache that this could turn out to be.
Now this is will be interesting to see and will give a killer reason for Apple Silicon. My guess is that this will take some years to be usable, given that Linux on M1 still isn't complete by the time M2 is announced.
But if a small amount of hackers were able to install Windows 11 ARM on a Raspberry Pi 4, then I won't be surprised to see the same to be done for Apple Silicon.
Funny, Windows on a Mac seems like total waste of time and hardware to me. Windows is ready to implode and stop being profitable with all of the CVEs and RCEs that are by design.
Do you think it would eventually be possible to run amd64 programs on it (like rosetta2 but for Microsoft Windows?) The main feature of Windows is legacy compatibility and that is perhaps why arm Windows doesn't seems to gain much traction.
Eventually I wonder if this project could be helpful to run wine on asahi linux, which would be awesome.
Windows on ARM supports that already[1]. The low traction is probably because of the (sorry) bad hardware. Windows branded ARM as the budget option so nobody wanted it. Then Apple came along and flipped the script.
ARM Windows (it was actually always THUMB2 Windows) was officially discontinued as of RT, without ever getting the x86_32 emulator let alone the x86_64 one.
But unoffically, there is a leaked build of Windows 10 15035 for ARM32, and it's possible to sideload it onto an original Windows RT device.
The x86_32 emulator was present in the ARM64 Windows release by this point, but, i don't know if the leaked ARM32 release includes an ARM32 version of the x86_32 emulator.
Project developer here, Windows actually has a x64 compatibility layer now for ARM64 systems in general, so any ARM64 Windows device should be able to run x64 apps (granted the performance penalty is worse than Rosetta since Rosetta relies on Apple SoCs actually implementing small slices of x86 (memory ordering model for instance) which isn't true for any Qualcomm SoC at the moment.)
The problem with x64 on arm64 is no longer if it's possible, but rather the performance penalty. As for whether I'll try to make a Rosetta-like compat layer using the hardware optimizations: not sure yet, I have bigger fish to fry before I get there.
The baseline for translation is qemu-user, but other pure-software emulators like FEX-emu and Box86/Box64 can perform this translation significantly faster. So I think there's just ordinary performance engineering to close the gap.
amd64 programs on Windows for ARM already work almost as well as intel mac apps do on an M1 mac with Rosetta2. Even in case of amd64, on Windows for ARM, on Parallels for M1 MacOS! This was true even 1 year ago.
I think Windows for ARM is still suffering from a previous release several years ago without the equivalent of Rosetta 2, and since then no hardware that actually offers an advantage in terms of battery life in the same way M1 macs did.
Interesting project. Not useful for me, but best of luck. Quick question: If Apple (working with MS) releases a blessed version of Boot Camp for running Win10 ARM on a Mac, does the project end? In other words, are there goals beyond what Boot Camp offers on Intel Macs?
People will reflexively see virtualization and figure it means noticeable hit in performance.
Unfortunately many Windows users and developers are unaware their "Desktop" becomes a VM on Hyper-V installation.
I see it all the time when people start arguing "type-1" vs "type-2" hypervisors.
Usually if they have some experience with Xen comparing it to a Dom0 helps, but understandably people usually first compare it to VirtualBox because the process is opaque.
At this point it would be hard for any normal user of Windows to tell the difference between the Intel and ARM variants of Windows 11. Things that haven't been ported to ARM will run slower, but they're already on par with low-end intel laptops.
Why does Asahi Linux exist when you can just virtualize it? Same answer: better performance, avoiding Apple, an interesting challenge, a learning opportunity, the cool factor, and many more reasons.
Because it perfectly satisfies the first guideline of "What To Submit":
> Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
Windows, for its many faults, is feature complete and officially supports ARM today. Neither is true of ReactOS. Thus, it's currently much easier and more useful to port windows.
ReactOS is nowhere near enough the quality you'd need - you don't want to waste time figuring out if you are fighting a bug in ReactOS or in your own code.
Agreed. Just last night I tried installing ReactOS in a Parallels VM on Intel, and their ISO installer couldn't get beyond "Failed to open txtsetup.sif" at the very start. The last ReactOS ISO I could get to work was 0.4.11 (three releases / three years ago). It's a worry that such a critical showstopper regression has gone unpatched over 3 years.
0.4.11 did run a lot of Windows software that I use (including my own) & I was impressed with what they'd achieved, but it regularly corrupted the file system and required a full reformat & reinstall, so not something I could actively use.
All the reasons are technical but nothing about an actual user need. Especially given the cost and complexity and most likely sub native window user experience this project seems to serve no actual utility.
I think booting Windows on a M1 qualifies as "actual utility" for a lot of people. Just because you don't see any value in the project doesn't mean other people agree with you.
Windows on M1 is a technical achievement but has seemingly no user benefits. User benefit would be better battery life, lower cost etc. This project has none of that. It's like running doom on a pacemaker, kind of cool but the feat is the end goal rather than delivering some real benefit beyond a technical POC.
I think it’s very hard to reverse engineer all the parts of m1. Such projects are fun research, but they won’t be able to use the full m1 potential. The software must be optimized as well.
1) yes, I realize this is going to be way harder than it seems, but I'm actually going to do my best to hopefully get a good user experience out of this and I'm easily preparing for this to be a multi-year effort, but I'm not going to give up right at the gate
2) Custom HALs were actually an option, up until very recently, since as of Windows 10, version 2004, the HAL is now statically linked into the kernel, meaning that if I wanted to use the AIC natively I'd need to write a patch finder that runs before the Windows kernel loads (This is what EfiGuard does for example to disable PatchGuard)
(Yes this is actually more tenable than it may seem, due to some undocumented policy files Windows is able to use, but I have already decided to hold off on this until after I get Windows working under the thin hypervisor)
3) HAL Extensions (for those unaware they are tiny modules that allow you to extend the Windows HAL with functions for non standard hardware) are not tenable at the moment since they're limited in the APIs they use
4) I am well aware that Windows is going to need a lot more help than just purely the interrupt controller, I'm currently trying to bring up the vGIC first since the distributor and redistributors need to be emulated and I need to bring up Project Mu first
5) as for the GPU, I'm way too far away from that being a concern to figure out the approach lol
if you have any feedback btw, please do feel free to comment it i'll try to address it as best as I can
yes I'll update the website theme soon enough, thanks to the commenter who remarked about readability.