Microsoft has never sustained Windows on any platform besides x86. 
What would make Windows on ARM succeed where others have failed?

I first wrote those words almost 11 years ago in Jan. 2011, and restated them then in May of 2012, before Windows RT (Oct. 2012-Jan. 2016) had even shipped.

The program to make Windows run on ARM (code-named “LongARM”) began in the Windows Core OS team… it must be nearing 20 years ago, when Longhorn was an overweight, out of control freight train overloaded with random features.

The belief that Windows could ever succeed on ARM was a moonshot that some within the org laughed off when the project was initially approved—but it was approved, and the team working on it did amazing work to make it happen – of course it didn’t see the light of day for quite some time.

I noted in that 2012 blog post that Windows NT had officially been ported to 8 different architectures. The last one I’d mentioned was an open-ended ARM SoC. That would be 32-bit ARM (ARMv7). Microsoft added a ninth architecture, ARM64/AArch64, to bring Windows on ARM to 64-bit.

I also noted the following:

If Windows RT succeeds, it will be due to the merits of the platform, the cost/power/weight/form factor of the devices, and the successful build-out of the Windows App Store.

What killed Windows RT? Exactly what I noted above. There wasn’t enough in the Microsoft Store to prop up the hobbled Windows RT platform. When Windows RT dead-ended, 32-bit ARM joined the graveyard of forgotten Windows NT architectures.

As we stand here, right now, Windows 10 and soon Windows 11 still don’t quite deliver full x64 emulation on ARM64. Customers also don’t seem to be picking up Windows on ARM devices, and continue leaning on x64. Why? If I were to guess, it comes down to cost given compromises, confusion with what they are, and unknowns as to whether the platform will ever be relevant, let alone whether it will live or die. The performance of x86 code emulation on Windows on ARM64 is… not great – particularly when compared with the performance of Rosetta-translated code on Apple silicon. But I’m not sure that most consumers have even made it far enough to ever know that, let alone notice it.

Moreover, the world has changed around Microsoft. Apple has:

1. Successfully begun their transition away from Intel
2. Delivered the first generation of hardware, to pretty resounding reviews
3. Provided a solid enough Intel code translation layer in Rosetta 2 that just works for most consumers.

Sure there are some hiccups. There are some high-end prosumers that Apple silicon (or at least M1) won’t necessarily work for. That’ll likely change, or they’ll be lost to the platform. But in general, Apple is pretty seamlessly succeeding at something that Microsoft has been trying for over 11 years to do, without success.

I noted on Twitter that I periodically like to search “Windows on ARM” just to see who is hanging on to the platform. What’s weird—particularly as a person who spends far too much of his work time writing and speaking about software licensing—is how it’s flipped completely from hardcore hobbyists trying to help Windows on ARM succeed, to conversations focused almost entirely on running Windows, in Parallels, on a Mac with an M1 processor.

Oddly specific, right?

All of this is purely anecdotal – but take a look at the following, captured during the second week of Sept. 2021:

The increasing fascination about running Windows on ARM on Apple silicon would be mind-boggling, if it wasn’t being pretty clearly promoted by Parallels as a key feature of their latest release, which supports Apple silicon. I mean check out the first item in the feature list on their site:

Microsoft has clearly noted, twice, that Windows isn’t available for use on Windows on ARM systems that didn’t ship with it from the OEM.

First in June, 2020, in a report on The Verge, in one of the earliest discussions that Apple was removing Boot Camp on Apple silicon releases of macOS:

and again more recently in The Register, as cited well on MacRumors:

Parallels’ current approach to getting Windows on ARM installed on Apple silicon systems to date relies on users enrolling in/being in the Windows Insider Program, and installing and running preview releases of Windows, not released, fully-licensed copies of Windows 10 or 11. I’ve wound up in numerous pointless debates on Twitter where people insist they’ve properly licensed their Apple silicon Macs for Windows—it’s pretty clear that that’s not possible, and that people who insist on going this route will be on their own in the future. Recent updates already appear to be hard-blocking updates of Windows 11 on M1 Macs. It’s likely that Windows 11 builds will eventually fail to work correctly on Apple silicon, particularly now that Microsoft has specifically called out that they will not be supporting Windows on the platform. Contrary to some of the tweets I’ve seen, if Windows on ARM breaks, this isn’t malice.

Let’s take a step back for a second. Why is Windows on ARM not thriving today? I believe it is some combination of the following:

1. Customer confusion/customer concern about the platform and potential limitations
2. Hardware performance – the Qualcomm processors required for Windows on ARM are not adequate
3. Software performance – the performance of x86 Win32 code emulation is not adequate
4. Software availability – the lack of x64 Win32 code emulation is a deal-breaker
5. Open software concerns – customers don’t know if the legacy apps or games they value will run.

Let’s go through each one of these quickly.

1: Customer confusion/customer concern about the platform and potential limitations. Most non-technical consumers likely couldn’t tell you the difference between an ARM-based PC and an x64 PC. But if my own anecdotal experience is any indication, potential sales of Windows on ARM PC’s are being actively snipped while they’re on the vine. Twice in the last year I’ve gone into the Best Buy in Bellevue, WA (the closest one of their stores to Microsoft’t Redmond HQ) to look at Windows PCs. Both times, I wandered into ARM-based PCs and a sales associate came by, effectively talking me out of the platform because of their assumptions that my software wouldn’t work on it. That’s not ideal. But given point 3, they’re likely right for some number of consumers.

2: Hardware performance – the Qualcomm processors required for Windows on ARM are not adequate. I don’t know what to say here, other than the fact that Apple silicon consumers are incredibly outspoken about how fast Windows on ARM is on the M1, vs. the performance of the OS on Qualcomm-based Windows PCs. Qualcomm-based PCs weren’t the fastest Windows RT systems either… it’s kind of peculiar that Microsoft wound up with them as their exclusive ARM partner – but they also burned a lot of partners along the way.

3: Software performance – the performance of x86 Win32 code emulation is not adequate. Not much to say here either. Pundits have generally had nice things to say about the Rosetta translation-based approach on macOS, vs. criticism of the performance of x86 emulation in Windows on ARM. I think to change this, Microsoft would need to fundamentally rearchitect how x86 code is supported on Windows on ARM—and if I were a PM at Microsoft, I’d be hesitant to do that given the low uptake of the platform. Not a great catch-22 to have to deal with.

4: Software availability – the lack of x64 Win32 code emulation is a deal-breaker. This one is peculiar. I have to periodically Google to see if Microsoft silently delivered this and I missed it. This article from six months ago discusses how development of the feature—first announced in preview over 10 months ago—would take some time… and it’s still not here? Once it does arrive, it’ll be interesting to see if the performance is better than Windows on ARM currently delivers for x86 Win32 applications.

5: Open software concerns – customers don’t know if the legacy apps or games they value will run. This is just sort of the “open issues” bucket; if customers don’t know that the apps or games that they value will run, or will run with adequate performance, they’ll generally step away from the platform and buy an x64 PC instead.

So… why do so many people want to run Windows on ARM on M1? It likely doesn’t solve many of the problems above. I think that—despite the hacks that need to be done, and despite the need to run Windows Insider builds—Windows on ARM on M1 appeals to consumers, in particular geeky consumers, due to the dramatically improved performance of M1 vs. any of the Qualcomm-based Windows PCs – even when Windows on ARM is running in a VM on M1.

Geeks may want Microsoft to bless Windows on ARM on Apple silicon. I know they do as I’ve debated it with many of them on Twitter… but it’s not the right move for Microsoft. Why?

1. Every M1 system that’s used to run Windows is a Windows PC that isn’t sold by Microsoft or their OEM partners.
2. Microsoft has no insight into or control over Apple silicon, unlike processors designed by or co-designed with Qualcomm or other partners. Microsoft would be completely at Apple’s mercy to support Windows on Apple silicon, and Apple would be able to decide when, or if, Windows works right on it. They already did that for the OS running on the hardware, with the nuking of Boot Camp. Microsoft would be tempting fate by trying to officially support running Windows on ARM in VMs on Apple silicon.
3. Apple does not, and will not, support the hardware (or virtualization of the hardware) that Microsoft needs to push the Windows 11 security perimeter that they clearly want to. Apple also doesn’t support nested virtualization; this absence will surely bite Windows 11 VMs in time.

It’s idyllic to say that Windows on ARM running on Apple silicon is a good thing. It’s handy for consumers. But Microsoft doesn’t build or test the OS to run on that hardware at all, doesn’t license Windows on ARM outside of OEM at all (as clearly stated by Microsoft) and likely knows that officially supporting Windows on ARM on Apple silicon would be an expensive, extended series of paper cuts. The company clearly realizes this.

I’ve said multiple times on Twitter that if Windows on ARM succeeds, it needs to succeed on the merits of Windows on ARM running on Microsoft-defined hardware. If it can’t succeed then, it probably wasn’t meant to. M1 is not a good long-term approach to spackle over any shortcomings of the Windows on ARM hardware platform.

For 15 years, the Mac and the world of Windows PCs ran on the same gauge track. A Mac could easily be a Windows PC. Between the death of Boot Camp and the move to Intel, and Microsoft’s multiple clarifications about not licensing and not supporting Windows on Apple silicon, Apple is running on a new gauge of track. It’s time to stop trying to make Macs run Windows. If you want to run Windows and run any app you want on it, buy an x64 PC.

If you want a Mac, buy an Apple silicon Mac. If you want to run Windows on ARM, buy a new Qualcomm-based Windows PC with it preinstalled. If you’re running either one and you need to run an old Windows app? Use Windows 365, VDI, or an older Windows PC to run it.

If you’ve been a fan of Boot Camp or making your Mac run Windows, this story doesn’t have a happy ending. It’s pretty clear that it’s over.