In my last post, I discussed the fact that Microsoft seems to have clarified whether people can license and run Windows on an Apple silicon Mac – and by and large, I think the matter is settled from a licensing perspective.

But I also mentioned that in terms of support, Microsoft’s representative told me the following through email:

“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…”

Microsoft response received via email.

This is important, particularly for businesses that have come to rely on Windows.

In the past week, I’ve seen two threads that concern me, as I see a little bit of a storm brewing.

If a customer hits an issue with Windows running on an Apple silicon (M1 or newer) Mac, or an issue with an application or other software running on said Apple silicon Mac, where is a customer supposed to go to solve the issue? The answer to this is thorny and complex, and… it’s probably not great.

One of these was an issue with Windows on ARM itself behaving unreliably under Parallels on an Apple silicon Mac. It would start, work, be suspended, and then fail to resume. To me, this is a Parallels issue to solve.

The other of these was an issue with an industry application designed for Windows on Intel. The person looking for help said someone else had gotten it working, but it would not work for him when he tried to run it on his Apple silicon Mac through Parallels.

Let’s take a step back for a second and clarify a few things.

On an Intel-based Mac, customers have come to rely on running Windows in one of two ways:

• Boot Camp – where the OS runs on the hardware of the Intel-based Mac itself
• Virtualization – where the OS runs within a virtual machine (VM) provided by a hypervisor – typically either VMware or Parallels.

Since both of these relied on a regular install of Windows (I’m trivializing a handful of things here), almost any application that would run on an Intel/AMD-based PC that shipped with Windows would also run on Windows when running physically or virtually on an Intel-based Mac. The key advantages of Boot Camp were (simplistically) three-fold:

• It didn’t require paying for a third-party hypervisor (only paying for Windows at retail)
• It let you take full advantage of all of your Mac’s performance (CPU, GPU, RAM)
• It let you play games and run other applications that do not run well or not run at all when Windows is virtualized.

On an Apple silicon-based Mac, customers really only have one way to run Windows:

• Boot Camp – where the OS runs on the hardware of the Apple-silicon-based Mac itself
• Virtualization – where the OS runs within a virtual machine (VM) provided by a hypervisor – most likely Parallels.

On macOS, Apple has intentionally broken Boot Camp. When you try to run the Boot Camp Assistant utility that would be used to configure the storage and install Windows, you are greeted with this simple message:

As I also noted in my last post, since Microsoft has been cagey about support, VMware—whose core business is the enterprise, not consumers first—has chosen to avoid promoting running Windows (on ARM) within a VM on Apple silicon Macs, even though they do have a preview release of their product that can run it. Hence, if you’re virtualizing Windows on an Apple silicon Mac today, you’re probably using Parallels, since they’ve been promoting the idea… for quite some time.

At this point, someone reading this is going to ask, “why is he ignoring X?” Where X could be WINE, QEMU, or QEMU’s fancier and more approachable cousin, UTM. It’s not that I have a vendetta against any of these technologies. However, WINE and QEMU are both infamous for being fussy (and sometimes/somewhat unreliable). Since UTM is QEMU under the covers, I’m throwing it in the same bucket. For me, it comes down to, “Could I reasonably expect a typical consumer to step through this process and rely on it day to day?”, or “Could I reasonably expect a business to rely on this technology for critical processes?” For me, WINE and QEMU do not fit perfectly in both of those buckets. While they may work for some people in some scenarios, they’re not great one-size-fits-all technologies.

As I wrote this, I realized that what’s really lacking is a frequently asked questions (FAQ) for running Windows on an Apple silicon Mac. So I wrote a second post, linked here, that discusses a bunch of issues and topics that I’ve seen come up in the Twitter community of users attempting to run Windows (on ARM) on their Apple silicon Macs.

Microsoft has a very terse and minimally helpful support article that discusses the limitations of Windows on ARM as a whole. Windows running on an Apple silicon Mac shares all of these limitations, and then some, since it is running Windows within a VM. (The latter means that in particular, you should couch your expectations when trying to run games on Windows on an Apple silicon Mac.

I say this article is minimally helpful because, while it lists a few Windows features that are missing in Windows on ARM, it completely omits the huge hurdles that will hit most users first. Let’s look at Microsoft’s list of things that won’t work unless they’re updated to run on Windows on ARM:

1. Drivers – Software that is written to allow hardware peripherals (printers, scanners, some musical devices) and some applications (games, apps, security software) to communicate with the lower levels of the operating system. Drivers must be updated and tested for each architecture that the OS supports. Many hardware and software vendors have not updated their drivers to support Windows on ARM yet.
2. Some games – Microsoft notes that OpenGL (a graphics rendering library) 3.3 is the latest version supported on Windows on ARM. Games that require newer versions of OpenGL will either not run, or run unreliably on Windows on ARM.
3. Apps that modify the Windows user interface – Because the Windows shell is an ARM64-based application on Windows on ARM, applications that tweak the user interface, integrate with some cloud storage services, implement assistive technologies, or use an input method editor (IME) may not work. Like drivers, the software vendor will need to modify, test, and release full ARM64 support for these applications.
4. Windows Fax and Scan – interesting. I’m sure that there’s some history that describes why this software didn’t make it to ARM64. It’s a sidenote in this conversation, though.

So I said that list is too short. What else is missing? Well, Windows on ARM itself also does not currently include the following features that are available in Windows running on an Intel/AMD processor:

1. Internet Information Services (IIS) – Microsoft’s web server platform, which is available for use on Intel-based versions of Windows, and used by developers. It’s just not there.
2. That’s it… well, that’s all that I can semi-officially find. Unfortunately Microsoft doesn’t document the differences between Windows on ARM and Windows very well.

Like 64-bit (x64/AMD64) releases of Windows, Windows on ARM does not support 16-bit x86 applications. Windows 10 also does not support x64/AMD64 Windows applications. What does this mean?

1. If you have an OLD 16-bit Windows/DOS application or software installer, it will not run on Windows on ARM, whether it’s Windows 10 or Windows 11
2. If you have a 32-bit (x86) Windows application, it should run on Windows 10 and Windows 11.
3. If you have a 64-bit (x64/AMD64) Windows application, it should run on Windows 11, but will not run on Windows 10.

So why do I say “should run”, instead of “will run”? Because Microsoft now includes Intel emulation that should let them run. However, if they rely on dependencies, libraries, runtimes, or other Microsoft or third-party software that isn’t included in or available for Windows on ARM, they may run unreliably or may not run at all.

Visual Studio – Note that while I’ve seen reports of people using it and it working or working to some degree, Microsoft does not support Visual Studio running on Windows unless it’s on an Intel/AMD-based system.

I’ve also seen issues with people trying to use the OpenSSH implementation included in Windows on Windows on ARM, as well as PowerShell (formerly PowerShell Core).

When it comes to Windows on an ARM Mac, should consumers expect that “this old Windows app” will work, or corporate customers expect that custom line-of-business applications will work? I don’t think it’s safe to say “yes”. Some applications and peripherals will never work in Windows on ARM without modification, whether running on an Apple silicon Mac or a PC with a Qualcomm processor (or something else someday).

Because Macs have been so popular with developers for so long, I’m also a bit concerned that developers are looking at Windows running on an Apple silicon Mac as a path forward, to replace running Windows on an Intel-based Mac or Intel PC. I think this is a really bad idea, particularly if the product they’re building is something that will run on Windows (or Windows Server) running on an Intel processor. Remember that there is still no ARM64-native release of Windows Server. Unlike Windows 11, Windows Server only supports x64 Intel/AMD processors today. There are a ton of caveats with treating Windows on ARM as a development environment, particularly if you’re building for Intel-based Windows. And because Windows on ARM is still a trivial part of Microsoft’s market, you’re building for Intel for the foreseeable future.

As Apple moves towards a world where 100% of Macs ship with Apple silicon, the reality is that more and more end-users (particularly consumers) will hit issues with running their software, peripherals (or both) on Windows with an Apple silicon Mac.

Another issue that developers in particular should expect to hit relates to nested virtualization. An increasing number of Windows features rely on nested virtualization if Windows is running in a VM itself. This is a complex concept, but it’s the idea of running a virtual machine… inside of another virtual machine. Very nerdy. But for features like WSL (Windows Subsystem for Linux), used by some developers and IT admins, which relies on running a Linux VM to deliver its capabilities, does not work on Windows on ARM when running on an Apple silicon Mac. Why? Because the virtualization stack that Apple provides on Apple silicon Macs, which is used by both Parallels and VMware on the platform, does not currently support nested virtualization. This means that some tools and approaches that developers have likely become accustomed to will not work unless Apple decides to change their infrastructure and support nested virtualization as well.

Before Microsoft acquired the Connectix technologies that eventually evolved to become Hyper-V, Microsoft used to have a standard perspective on support when you hit an issue with their software running in a VM. You needed to reproduce the issue on a physical system before they would debug and support it, to ensure the issue wasn’t with the hypervisor itself.

Because we’ve stepped back here, and the only way to run Windows on an Apple silicon Mac is within a third-party hypervisor, Windows 11 has new, complex hardware requirements, and Microsoft doesn’t explicitly support Windows when running on Apple silicon. If a customer hits an issue with Windows or an application on Windows when running in a VM on an Apple silicon Mac, I fully expect Microsoft to ask customers to reproduce the issue on a Qualcomm-based PC that shipped with Windows on ARM before Microsoft will take the issue on and escalate it, trying to support the customer.

Consumers and businesses grew accustomed to treating Macs as PCs over the last 15 years. It’s pretty clear that there’s about to be some new friction introduced here, and things that consumers will expect to work “because they’re using Windows” won’t necessarily work. And it’s unclear who they’re expected to turn to to resolve these issues if they’re running Windows on their Apple silicon Mac.