In my experience all the insider builds I have used had expired at some point (but maybe some have found insider builds that never expire...). The only one that works with no expiration (since it's not an insider built) is the one that Parallels started using last year with their 17th edition (they donwload it automatically when you install Windows 11).. I have tried to see if I could make it work with free alternative from competitors but no, apparently it works only with parallels...
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Why doesn't Apple Silicon support Windows on Arm if it supports Linux on Arm?
- Thread starter izzy0242mr
- Start date
- Sort by reaction score
That would be the only way I'd be comfortable with it for work unfortunately. And it's definitely Windows on Arm! (or just Windows that happens to be running on a Qualcomm based PC.)
Again. It’s NOT an insider nor preview build and has not been for a long, long time. It is know as Retail Channel.
I know because I was an early adopter and downloaded the insider build with Parallels. That changed a LONG time ago and now you are getting a full ARM build. I can’t be more clear. You can also look this up on Parallels forums. It has been confirmed over and over.
Last edited:
It looks like VMware Fusion supports running Windows 11: https://www.vmware.com/products/fusion.html
I downloaded ARM for windows for my MBP and I'm personally unimpressed. Apple has done a much better job with its Rosetta 2, then MSFT has with their emulation.
There's also MS' Dev Kit available for sale as well
Parallels does as well, and if I were to choose either one, I'd pick Parallels they have a better track record for Mac support imo
I'm not impressed with it either, but it does in a pinch most of the time. The licensing bothers me more than the compatibility for most things.
Yeah, but it's a qualcomm processored mac mini looking thing. I don't really need to develop anything for Windows Arm stuff, I'll stick with x86/64. The only reason I'm interested in Windows on Arm is I have a Mac Studio at home and I hate switching machines in the middle of something.
I am 100 percent sure that if you were at the right place at Microsoft, you would see an Apple Silicon system that is running Windows for Arm. Now the question is do they run it like Linux runs with the security turned off, or do they have a bit of help from Apple to run it totally natively.
Here's some clarification on this, including this statement from Microsoft:
oofhours.com
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.
Microsoft will let you run Windows 11 on an M1 Mac, but they won’t support it
In a previous blog post, I talked about two products that enabled running the ARM64 version of Windows 11 on M1-based Macs, Parallels Desktop and VMware Fusion. Both work reasonably well, but there…
oofhours.com
Interesting. That's actually still not Microsoft saying it's licensed directly, but someone called "Directions on Microsoft (Directions) is an independent IT planning information and advisory service focused exclusively on Microsoft since 1992" That link above about compatibility still doesn't have the Mac, or generic ARM processors on it..Here's some clarification on this, including this statement from Microsoft:
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.
Microsoft will let you run Windows 11 on an M1 Mac, but they won’t support it
In a previous blog post, I talked about two products that enabled running the ARM64 version of Windows 11 on M1-based Macs, Parallels Desktop and VMware Fusion. Both work reasonably well, but there…
They really should know since one of their expertise is licensing -- but still not enough for corp work for me.
Actually, the quote appeared in https://getwired.com/2022/02/03/can...on-an-apple-silicon-mac-after-all-it-depends/ , but it's from Microsoft itself:
Cool, that's a much better explanation and it at least attributes the quote to Microsoft.
So licensed, yes(!), support, no. That actually takes a load off my mind in using WoA at home for some work. I'll still keep my Windows PC's too, but at least I wont have to switch machines if I get a call and I'm on the Mac. So thanks!
Thanks. That is the first definitive response that I've seen. Unsupported but not breaking copyright if you have a license.
I was amused by this part though:
I guess you can say that Apple broke boot camp intentionally but that seems an odd way to phrase it. Apple didn't implement boot camp on Apple silicon because they don't use a boot process that is compatible with Windows. Obviously they could if they wanted to but that would compromise their new boot security. But otherwise an informative article.
It's not that Apple Silicon can't run it it's that Windows for ARM is only officially available to OEMs it's not something sold to the public. So Apple can't officially support that.
Microsoft really needs to up their Windows 11 on Android chips game further. x86 is just ineffiient at this point that depends on legacy support and backward compatibility on old & current software to stay relevant.
Today's Android phone using 5-7nm chips has a superior performance per watt and power efficiency than any Intel 14nm chip made from 2014-today.
Today's Android phone using 5-7nm chips has a superior performance per watt and power efficiency than any Intel 14nm chip made from 2014-today.
No, as people here keep trying to explain Windows for ARM wouldn't "just work" on Apple Silicon if only MS sold licenses (which, as several posts have already confirmed, they do) and Apple gave the thumbs up. Intel Macs were a gnat's whisker and a missing EFI firmware module away from being PC clones with nicer trackpads - on some models, you could just stick in a Windows XP DVD and boot the regular installer. Bootcamp assistant was exactly what it said on the tin - a point and click assistant that smoothed some of the rough edges. In particular, the graphics was provided by bog standard Intel, AMD and (early on) NVIDIA GPUs which already had Windows drivers.
In contrast, about the only thing an Apple Silicon Mac has in common with a Windows on ARM machine like the Surface X is the ARM instruction set (and there are even some gotchas there). Windows is not going to boot on Apple Silicon without some significant changes under the hood, to bootloaders, installers etc. including a ton of newly written drivers for I/O etc. and - in particular - native Windows drivers for the Apple Silicon GPU, which is very different from anything on the PC. Boot security is part of that problem but it's not the whole problem. Windows 11 on Apple Silicon would be pretty useless without a good, native, accelerated graphics driver.
So - sorry, conspiracy fans: licensing issues, the Evil Overlords of Planet Q'ualcomm etc. may have a role to play, in this but they'll have to take their turn behind "Bootcamp for Apple Silicon" simply being easier said than done. It would surely be possible with effort, but it's as clear as mud why Apple would want to promote the Mac as a Windows machine and/or why Microsoft would want to promote a CPU that was only sold in Macs & couldn't be licensed by the 101 clone maker that are the backbone of the PC market.
Running WoA under Parallels, VMWare Fusion or UTM is another kettle of fish: hypervisors can emulate hardware/firmware environments that are supported by WoA and things like graphics are handled by "stub" drivers that take Windows graphics calls and pass them to the official MacOS drivers running on the "host". Apple have clearly said that they will support alternative OSs under virtualisation, not direct booting and, if you read it in context, Apple's "up to Microsoft" comment was clearly referring to using MacOS's virtualisation tools (before Parallels and VMWare stepped up).
Last I looked, Asahi Linux didn't have accelerated graphics - maybe not a problem for many of the things Linux users want to do - but Windows users going to the rouble of running BootCamp rather than virtualisation often do so because they want better graphics performance - particularly on AMD. BootCamp'd WoA without decent native graphics drivers isn't gonna be a lot of use - Parallels would probably do better - and DirectX-optimised Apps are probably never going to shine on the Metal-optimised Apple Silicon GPU.
They are working on it. Reverse engineering takes time.
They made tremendous progress (and broke a bunch of milestones at the same time, e.g. delivering the first ever GPU drier written in Rust!), but reaching the full performance potential is an entirely different matter.
I'm quite confident that DX12 can be reasonably run on top of Metal, but it will be much easier to write a compatibility layer that enumerates the API (like what MoltenVK does) rather then trying to write a full stack of DX, GL and Vulkan drivers for Apple GPUs directly.
CodeWeavers expects to implement DirectX 12 compatibility as early as CrossOver 23. In fact, @leman has debunked some of the misconceptions that CodeWeavers wrote in that article. I hope they took notice.
BTW, Apple has updated the support documents to clarify that one can access one million textures per stage, which is the same as DX12 (with the difference that a metal has no limit on how many resource bindings you can have in general). Again, different API philosophy.
Which is really my point - Asahi Linux has achieved impressive results, but at the cost of a lot of work (much of which, being Linux, won't be "billable hours") - even if they're not being supported by Apple, they've got a lot of experience in reverse-engineering Apple hardware plus full access to Linux and related source code (and The Great Penguin himself as an enthusiastic supporter). WoA could undoubtably be made to run well on Apple Silicon - but it's not "low hanging fruit" like Intel bootCamp and would take significant investment - which leads to the question of "where's the market and who benefits?".
Sounds like a hypothetical Windows-on-Apple-Silicon would address a narrowing niche between the performance you could get out of a VM hosted by MacOS and what you could get out of a "real" PC with AMD or NVIDIA GPUs. It's looking like Parallels is already providing "adequate" performance - the question is whether there's an "easy" route for WoAS that would do significantly better than VM.
I guess I just don't get what people actually want (natively booting) Windows on ARM for - even if it happens it's never going to be quite as seamless and well-optimised as Intel Bootcamp. At the end of the day it's still Windows on ARM when the "industry standard" is still x86 and - unlike Apple - Microsoft doesn't have the leverage to force a new processor architecture on the Windows world. The VM route will solve most "switchers" problems (as, I suspect, will cloud PCs & remote desktop in the future).
There is some efficiency overhead associated with GPU API emulation, plus, there are some things that Metal might now expose but are supported by the hardware (like the additional primitive types). But frankly... these things should not matter much in practice. The main point of the API is to submit work to the GPU, if you have an application where API calls are a CPU bottleneck then you are doing it wrong anyway(*)
Probably the old naive "VMs slow", "native boot fast". Go figure.
(*) I just recently spent some time on a GPU programming forum arguing with people who were very convinced that Vulkan is better because it uses fixed-layout structs and simple function calls instead of more abstract interfaces. Makes the API "faster", they said. As if saving a dozen or two of machine cycles on API call will make any difference at all if you have to do a user/kernel transition to hand the data off to the GPU... the lack of system programming education and understanding in the C++ crowd is frankly staggering. It's like most actually good programmers left for Rust or something...
Well, its already pretty common practice in the server/cloud world to install a bare-metal hypervisor first and run everything as VMs. I would be totally unsurprised if, in the not too distant future, most PCs will work that way.
- along with moving even further towards shipping applications as bytecode rather than processor-specific binaries (AFAIK Microsoft's common language runtime already does that, and I believe the Apple App store has the capability to generate processor-specific binaries on demand from bytecode). It would be nice to think that the x86 to ARM transition will kill off the remnants of lovingly hand-crafted x86-only code and will be the last time that changing ISA is a big deal.
That's the way Windows does it when you have Hyper-V installed, everything is a VM, with the host VM having special hardware access. (and a heck of a lot of tuning to make it work as fast as a non-VM.)