Running Windows natively on M1 Macs


Arstechnica just posted an interview with Apple senior executives Craig Federighi, Johny Srouji, & Greg Joswiak to talk about Apple’s M1 SoC. Here’s an interesting tidbit from Craig Federighi mentioning running Windows natively on M1 Macs;

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.”

“Federighi pointed to Windows in the cloud as a possible solution and mentioned CrossOver, which is capable of “running both 32- and 64-bit x86 Windows binaries under a sort of WINE-like emulation layer on these systems.” But CrossOver’s emulation approach is not as consistent as what we’ve enjoyed in virtualization software like Parallels or VMWare on Intel Macs, so there may still be hills to climb ahead.”

Comments (32)

32 responses to “Running Windows natively on M1 Macs”

  1. waethorn

    Windows on ARM is locked behind an OEM NDA license that is similar to the NDA's signed by the embedded channel. It is not openly accessible to users, thus not downloadable to install in an environment that is not locked to a piece of hardware. It requires an OEM contract that includes a specific distribution agreement that states it only be distributed on new, certified hardware (i.e. WinQual/WHQL-logo'd) with firmware components, such as the MSDM table with an activation key, embedded in UEFI firmware with Secure Boot including Microsoft's code-signing certificate, already pre-embedded in the system. Likewise, Microsoft includes specific hardware requirements as part of that agreement, such as specific SSD and processor capabilities. There also has to be drivers written for Windows that support the emulated environment's virtualized ARM hardware, and that means that Microsoft would need help from Apple to do that.

    My advice: buy a cheap Windows micro-desktop box and remote into it to run your Windows software because you won't see Microsoft change this any time soon.

      • waethorn

        In reply to jimchamplin:

        This proves my point. The download is not official. Likely some employee of an OEM is leaking these URL's online. Microsoft has a strict NDA with companies over this and I'm sure they'd heavily penalize that OEM if they found out who was leaking it. When an OEM produces a product with it, they have to base their image on the vanilla one, just like any other OEM, much like how Android OEM's base their OS images on AOSP - but are not allowed to just include the vanilla image.

  2. madthinus

    What would be the point? All mainstream software that is needed on the Mac is supported. Why would you need Windows? cheaper and easier to pick up a surface laptop / Pro and run your apps on that when needed.

    • reefer

      In reply to madthinus:

      Exactly, there is no point for Microsoft to vaste resources trying to run Windows natively on Apple Silicon for the very tiny percentage of users that for some odd reason need it when that can be fully satisfied running it in a VM.

  3. Alastair Cooper

    In reply to Bob_Shutts:

    Fastest Windows performance in that *category*, plus I doubt Microsoft's x86 emulation is as performant as Apple's so older apps may be quite slow.

    Apple haven't released anything that can compete with AMD's Zen 3 which is the performance leader, and probably a few notches below on current generation chips. If they were to somehow do that though . . .

  4. Alastair Cooper

    It should be possible to run x64 Windows under emulation (not natively, by definition) but I have no idea what the performance will be like.

  5. longhorn

    It wouldn't make any sense for Qualcomm to run Windows natively on an Apple SoC.

  6. reefer

    It wouldnt make any sense for Microsoft to run Windows natively on an Apple Silicon mac.


      In reply to reefer:

      I agree. I ran a boot camp partition for years, and then a Fusion VM for the one or two apps that I needed. But today I have a separate desktop PC for gaming and all the Windows Apps I need. The 16" MacBook Pro is 100% MacOS. Since moving into Web Development, I can be equally productive on either machine.

      Also it's good to have a backup computer, in case the desktop PC goes down. Yes - that has happened twice now. I guess the PC can backup the MacBook should it go down, but since 2007 My MacBooks have been rock solid.

    • Alastair Cooper

      In reply to reefer:

      Why not? It's another opportunity to sell Windows licenses at the very least.

      • wright_is

        In reply to Alastair_Cooper:

        It comes down to the investment and the return on it.

        They will need, probably a couple of years to convert it to the Apple M1, for relatively few licences.

        The Snapdragon code won't run on the M1.

        • shameer_mulji

          In reply to wright_is:

          "The Snapdragon code won't run on the M1."

          It doesn't have to. From what I understand the NT Kernel is designed to be architecture agnostic, like macOS.

          • jimchamplin

            In reply to shameer_mulji:

            That’s correct. NT has a hardware abstraction layer (HAL) that takes care of most cross-platform issues.

            But the code will likely run - without optimizations - unmodified. Remember that Windows 10 “for Snapdragon” runs on the Raspberry Pi, of which the RPi 4 uses Broadcom silicon.

            All ARM CPUs use the ARM ISA, so the core code will run anywhere the ARM ISA is implemented.

            • wright_is

              In reply to jimchamplin:

              Windows for Snapdragon doesn't run on the raspberry pi. That is Windows 10 for IoT, something else again.

              The kernel will need to be rewritten for the M1, or at least the HAL, it is a lot of code and will need a lot of testing.

              The problem isn't the ARM code but all the support hardware, which is different for every SoC.

            • waethorn

              In reply to jimchamplin:

              It has to include drivers for the SoC, and it also requires a firmware that complies with UEFI 2.3.1. Apple doesn't have any drivers for Windows, and there's no evidence that they use UEFI on their ARM macOS platform since they already don't on iOS devices. Even if they did, there's more than a good chance that they lock down boot loader support to macOS using functionality akin to Secure Boot. They talked about security features like this coming to their ARM Mac's before.

              • jimchamplin

                In reply to Waethorn:

                No I'm pretty sure you're right it's a custom firmware. From the sound of things though this is a surmountable issue. Perhaps even to the point where Apple will let Microsoft sign Windows. Who knows? At this point, nobody, since it's not even an issue. As far as we know, MS has no intention of an M-series release of Windows.

                There are clearly technical issues, as there are in any port to a new platform. The point I was making below is that even WOA as it stands isn't indelibly tied to Qualcomm's CPUs, as all ARM CPUs must use the same core ISA. Runs without modification on RPis. Perfectly? No. Competently? Yes. Officially? Hell no.

                • waethorn

                  In reply to jimchamplin:

                  WHAT? Microsoft signs Windows already. What Secure Boot does is only boots boot loaders that match digital signatures for certificates stored in Secure Boot.

                  Runs without modifications, and "competently"? You need to have your head examined.

                • wright_is

                  In reply to Waethorn:

                  Except Apple uses its own custom method and they issue the master keys for the signing, not Microsoft.

                • waethorn

                  In reply to wright_is:

                  Right, which is exactly why Microsoft won't do this. Nobody even seems to know what their boot firmware does outside of the Intel Macs, and that boot procedure uses some kind of UEFI now, but it's not even determined if their firmware is fully UEFI, or if UEFI is just emulated for alternate operating systems. ARM SoC's don't have a unified firmware interface - Microsoft only mandates UEFI+ACPI functions for Windows-on-ARM so that they don't have do the work to port it to a custom firmware interface. Apple could be using something entirely incompatible with the Windows boot process. And if that's the case, they'd still have to implement UEFI functions to allow for alternate operating systems.

                  Microsoft won't release an operating system for a hardware platform when they know it can't run natively on it because there's no validation for it. If anything, they'll release it as a pre-baked VM, but the chances of them doing that is zero to zilch.