The current version of Windows on ARM contains Prism, Microsoft’s emulator that allows x86-64 code to run on ARM processors. While it was already relatively decent on the recent Snapdragon X platform, it could still be very hit-or-miss with what applications it would run, and especially games seemed to be problematic. As such, Microsoft has pushed out a major update to Prism that adds support for a whole bunch of extensions to the x86 architecture.
This new support in Prism is already in limited use today in the retail version of Windows 11, version 24H2, where it enables the ability to run Adobe Premiere Pro 25 on Arm. Starting with Build 27744, the support is being opened to any x64 application under emulation. You may find some games or creative apps that were blocked due to CPU requirements before will be able to run using Prism on this build of Windows.
At a technical level, the virtual CPU used by x64 emulated applications through Prism will now have support for additional extensions to the x86 instruction set architecture. These extensions include AVX and AVX2, as well as BMI, FMA, F16C, and others, that are not required to run Windows but have become sufficiently commonplace that some apps expect them to be present. You can see some of the new features in the output of a tool like Coreinfo64.exe.
↫ Amanda Langowski and Brandon LeBlanc on the Windows Blog
Hopefully this makes running existing x86 applications that don’t yet have an ARM version a more reliable affair for Windows on ARM users.
Well that’s good, supporting these CPU extensions is clearly important for software emulation. Honestly if I were on the market for one of these windows ARM laptops, software compatibility would be a top concern of mine. Pcmag, tested several programs in july and while some things worked it was really hit and miss (even before talking about performance).
https://www.pcmag.com/articles/how-well-does-windows-on-arms-prism-emulation-work-we-tested-with-31-apps
Maybe more programs could work now with more CPU features implemented, although I suspect many programs will still fail for other reasons. The lack of 32bit support, applications that “helpfully” refuse to install/run on an ARM cpu regardless of whether the emulator can support them. And one big problem with buying these ARM computers for windows is that you don’t know what x86 software will actually work before you buy it. It shouldn’t be beyond microsoft to fix all of this, but they seem to be taking their sweet time. I wonder if microsoft’s ARM initiative only exists as a hedge against intel and AMD for negotiations rather than giving ARM the first class treatment.
It doesn’t support 32-bit? Even M1 supports 32-bit x86 code (unofficially). That’s kind of dumb.
CaptainN-,
I didn’t know apple still supported 32bit (even unofficially). But yeah for windows it’s a problem. A lot of business software never transitioned to 64bit because there was never a benefit. But even 64bit software could face a problem if a 32bit installer can’t be run to install the software.
Microsoft’s commitment to ARM seems to be very weak. This was a stark difference between apple and microsoft,
Apple’s x86 subsystem (Rosetta 2) does support 32-bit code – that’s why you can run old Windows games under the various Wine/Whiskey platforms.
Strangely, they do NOT support 32-bit macos binaries, which means it’s easier to run old 32-bit x86 Windows games, than 32-bit x86 macos games. Apple does Apple.
Not strange at all. Apple is a hardware company. They need people to buy new hardware. An important part of that is making sure that the applications that people need to run do not run on older hardware. They can directly control the operating system and so they ensure that it only supports the last 5 – 7 years of hardware. In the operating system, they add and deprecate features so that applications have to move to the new OS which means driving new hardware sales. They cannot do this for Windows applications though.
This is basically their own version of rosetta.
But without the option Apple had of having a clear roadmap of migration coupled with the hard stop.
Apple knew that the big apps would all move to arm,because in a few years their apps wouldn’t have a native option as Apple stopped selling x86.
Also they can drop OS support after a couple of years.
Adurbe,
Yeah. As a user I wouldn’t like apple dropping compatibility, but there’s no doubt that being able to deprecate old software interfaces is an operational advantage for apple. On windows, while compatibility doesn’t always hit the mark, there is a much higher expectation of long term software compatibility – it’s a big reason for businesses standardizing on windows & x86.
This is one of the reasons I don’t think Microsoft will ever really put the necessary energy behind ARM to make it successful. They tend to follow trends, rather than lead them. That could change, if enough ARM vendors start producing chips for Windows to run on – nvidia maybe especially. (I also want to see x86 memory modes supported in hardware on the Windows side, which I haven’t seen yet.)
Mamy years ago i would like to have ARM cpu in PC, but now when I’m older i just like things that work. I rememer my first contact with Chrome OS. After 2 days I’ve returned my Chromebook and bought normal laptop with Debian on it, so my old games and programs worked with WINE without problems. Solvings problems that is made by platform itself isn’t fun for me anymore. Buying incompatible hardware and try to fix it with software… Nah. However it’s good for people that got it from somewhere for free.
Those cpus will be fine for people that just work online. Why use resources to emulate other hardware, when you can just buy other hardware. But maybe I’m wrong and soon arm will be efficient enough to emulator and still get better performance than x86 cpus.
Marshal Jim Raynor,
Emulation should be the exception rather than the norm. When apple committed to ARM, it was crystal clear that ARM was the future of apple products and that emulation was just a transitional process. Windows is a different monster, Buyers of windows ARM computers have to deal with the fact that much of that software will not be ported. As a long term solution, emulation is much less appealing and IMHO harder to justify.
Linux distros have a huge advantage on ARM because the majority of open source software can be recompiled and distributed as native without a hitch. Even years ago I found switching to ARM on linux was a transparent process for the software I used. Of course it couldn’t match the performance of x86. Newer ARM computers should fair better with performance. My main gripe with ARM is that we loose the ability to treat hardware and operating systems as generic interoperable parts leaving us heavily dependent on manufacturers to support operating systems and software, which IMHO is a terrible place to be. As a rule, I aim to not be dependent on manufacturers for anything other than hardware so that I can avoid obsolescence. Unfortunately though ARM makes it much harder to carelessly slap on the generic distro of my choice and go on with life, the ARM experience is more tethered and less liberating.
Linux support is maybe even better than I expected at this point and really coming along. I just saw this:
https://discourse.ubuntu.com/t/ubuntu-24-10-concept-snapdragon-x-elite/48800
According to that link, this release of Ubuntu is “working” on all of these devices today:
ASUS Vivobook S
Dell XPS 13 9345 (32GB and 64GB)
HP Omnibook X 14
Lenovo ThinkPad T14s Gen 6 (32Gb and 64GB)
Lenovo Yoga Slim 7x
There are certainly lots of open bugs but, after a casual reading, it seems like these systems are fairly usable already and improving fast. The boot process in these devices is fairly standardized I think and the device tree issue is probably temporary. Things are not as “universal” as X86 just yet but I think X Elite shows that the ARM world can get there. X Elite is still in its infancy. Baby steps.
LeFantome,
Yeah, Honestly I’m tired of these “baby steps” since I’ve been waiting and wanting for decades. But if the barriers can finally be tackled, then better late than never.
I’ve scrolled through dozens of these snapdragon laptop listings, but I’m very picky about keyboard layouts and I don’t like where the industry is at. I DESPISE keyboards that place “home” “end” “pgup” etc keys in the top row and it’s even worse when you need to hold down FN + F9 through FN + F12 to use them. On top of that, those keys are right next to the power button, you just know that’s going to be hit accidentally. I’ve never used it and I already want to throw this laptop out the window, haha…
https://www.bestbuy.com/site/microsoft-surface-laptop-copilot-pc-13-8-touch-screen-snapdragon-x-plus-16gb-memory-256gb-ssd-7th-edition-platinum/6582826.p?skuId=6582826
This one’s better, but I hate having to rely on the FN button for normal keyboard navigation. I hate that microsoft’s “copilot” keys are polluting our keyboards. I suspect it’s an OEM requirement, but it’s crap!
https://www.bestbuy.com/site/lenovo-yoga-slim-7x-copilot-pc-14-5-3k-oled-touch-screen-laptop-snapdragon-x-elite-16gb-memory-512gb-ssd-cosmic-blue/6582538.p?skuId=6582538
These complaints aren’t mere gripes for me, my productivity serious tanks when laptop designers decide that navigation keys should be second class citizens, making them way too small, peppering them around the keyboard where they make no sense, overloading them with FN modifiers. It’s not just single keypresses either, I like using CTRL & SHIFT along with nav keys to quickly select text, it’s muscle memory. But far too many of these keyboards are junk and I have to resort to slower mouse input and key pecking, which I hate but it’s not my fault when it’s the byproduct of an industry that doesn’t really respect typing any more.
This is O/T, but finding a laptop I like feels like searching for unicorns. It shouldn’t be this hard, haha.
I am very much considering one of the X Elite laptops. I primarily use Linux and I expect that the vast majority of what I need to run can just be compiled.
That said, I rely heavily on the repos in my distro of choice so I would need to test ahead of time if all the software that I use is available. There may also be more assembly than I realize holding some things back. I use the SVT-AV1 encoder quite a bit as an example and it for sure uses some hand-rolled assembly to do its thing. That said, I notice that a 30% speed-up on ARM was featured in the most recent SVT-AV1 release notes. So I expect that at least that software will work. With so much Linux being used in the SBC space ( like Raspberry Pi ), I am hoping that the ARM ecosystem is quite far along.
I know that Thom has complained that Qualcomm is missing their commitment for Linux support on X Elite but, as far as I can tell, it is coming along pretty well. There was a bunch more support in the 6.11 kernel for instance. As for end-user hardware ( not just the CPU but full systems ), device tree support is still required but at least a couple of laptops ( one a Lenovo ) seem to be in decent shape. I need to do some more homework but it feels like Linux on X Elite may already be in a pretty similar spot to Apple Silicon which of course has taken much longer to get where it is. I assume the Apple Silicon users have helped firm up the Linux on ARM support as well.
“now when I’m older i just like things that work”
I just switched back to Windows on my gaming PC for that reason. It broke my heart, but I was tired of fiddling with Linux to try and get HDR working. It’s not that you can’t use Linux relatively easily (it really has never been easier), there are just always edge cases that don’t work, and I want to be able to use this thing on with HDR on my OLED TV, so here I am, back on the clown show that is Windows… for now.
I did make sure to buy AMD when I upgraded my GPU though – just to keep my options open, and I still have Linux on my productivity focused laptop, Steam Deck, and homelab server(s), so I’m not a complete sell-out. 😀
I know everyone hates the new Intel chips (Lunar Lake – Core Ultra 200V – mostly because they are too expensive for the performance on desktop – I bet a lower price point would reduce the hate). I’m curious how they are going to stack up against ARM on mobile/laptops though, especially for emulated x86 work flows on ARM vs native performance on Lunar Lake.
x86 was never intrinsically slower, it’s just that Intel and AMD haven’t put the effort in to improve their power envelops in those use cases. Well now that Intel has (and sacrificed some performance to do it.) I wonder how the numbers will shake out in performance to energy use terms (e.g. battery life.) It might actually be too late to counter the cultural narrative, but when has cultural narrative ever tracked to facts?
(They do still need to adjust their total package against Samsung though – webcam, and all the rest. That’s the other unspoken weakness with Intel/AMD in laptops which also has nothing to with x86, but is still a very big problem.)
CaptainN-,
x86 was never intrinsically slower, but the complexity of the architecture requires a lot of transistors, which takes a lot of power. The ratio of this overhead compared to transistors actively doing work depends on exactly what is running on the CPU. If you’re running highly intensive computations like AVX instructions, the overhead is slight by comparison. However if you’re running things like node.js, php scripts, etc running long sequences of instructions that aren’t computationally intensive, this is when I’d expect architectural complexity overhead to become most significant.
Er, I meant less efficient (wrote the wrong word). Also, number of transistors does not translate directly to power usage. So many myths to counter!
CaptainN-,
No problem, none of us have an editor, haha.
I thought we discussed it before, but it’s not so much about the number of transistors on a die. but the duty cycle of those transistors that matters. This is why I stress the importance of looking at specific workloads since that makes a difference.
Consider that lots of transistors are used to implement features like AVX, but whether they are completely idle or going full tilt depends entirely on the software and this can impact software efficiency between architectures.