My RTX Spark laptop runs Cyberpunk and Forza without a hitch, but Windows on Arm still can't shake its x86 baggage

Published Nov 2, 2026, 12:01 PM EST I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I'm XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017. In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as AdamConwayIE, or u/AdamConwayIE on Reddit. Sign in to your XDA account For the last few weeks, I've been using HP's OmniBook Ultra 16 with Nvidia's RTX Spark, and a lot of things work surprisingly well out of the box. Games like Cyberpunk 2077 and Forza Horizon both run despite going through Microsoft's Prism emulator, and other, standard applications tend to just work without a hitch. Just a couple of years ago, playing a demanding x64 game on Arm would have been unthinkable, yet now it's just an expectation. Despite that, I've ran into numerous roadblocks when venturing off into the unknown. Connecting an RTX 4080 in a Thunderbolt enclosure? Won't work. Everyday Python dependencies? Good luck. Your VPN? Even that might not work, depending on whether Microsoft has signed the driver for it yet. My M4 Pro MacBook Pro is also an Arm machine, but my dependencies and my VPN work just fine. Windows is in a bit of a strange spot right now, and there's only one question that will decide where all of this goes: will Intel and AMD close the efficiency gap with Arm before Microsoft can transition the Windows ecosystem away from x86 assumptions? Nvidia's RTX Spark works well The chip isn't the problem When I plugged the RTX 4080 in Plugable Thunderbolt 5 enclosure into the OmniBook, Microsoft's Arm64 USB4 drivers were able to establish a PCIe tunnel at Gen4 x4 without issue. Windows detected the card just fine, but Nvidia's Arm64 drivers for Windows don't include the RTX 4080's device ID, causing it to fall back to Microsoft's Basic Display Adapter. Both the hardware and the USB4 drivers worked, but the missing driver was Nvidia's. Python was a similar story; torch, OpenCV, CTranslate2, sqlite-vec, and cryptography lacked Windows on Arm wheels on PyPI, yet all five have Arm builds available for Linux and macOS. OpenCV's absence also causes problems for things like RapidOCR and PaddleOCR, and in my testing, Qwen 3.8 Flash Next had to resort to using Windows' own OCR API instead. Which was fast, to be fair. PyTorch has Windows on Arm builds, but they're CPU only, while Linux on Arm and Windoww on x86 have CUDA-enabled builds through PyTorch. Nvidia publishes CUDA-enabled Windows Arm64 PyTorch packages separately, specifically supporting the RTX Spark, but you need to install them through Nvidia's package index. The GPU is CUDA-capable on both Windows and Linux, but the framework packages depend on which platform you're using and where you get them. Even Steam lacks an official Arm build. Valve does ship a native (but beta) Arm64 Steam client for Linux, yet its Windows client is still x86-based. For many companies that still publish x86 builds of their software, there simply isn't an incentive to put effort into building for Windows on Arm. After all, if it runs through Prism, what's the rush? Windows on Arm is built to carry x86 along It even puts fake x64 code in its own functions Prism is pretty good, and it's been improving over the past couple of years. For example, in 2025, it gained support for AVX and AVX2 instructions in 2025, which opens the door to a lot more photo editors, video editors, AI runtimes, and some games that previously wouldn't run. Prism, though, only translates user-mode code, and kernel drivers need to be built as native Arm64. This means that any x86-only kernel driver, be it for an audio interface, VPN adapter, anti-cheat, or GPU, needs a native Arm64 driver. VPNs are a great example of what this looks like in practice. WireGuard has its own driver for Arm64 support, and it works with emulated applications just as well. Popular VPNs like Windscribe, Proton, and Mullvad released native Arm64 builds in May 2023, November 2024, and February 2025 respectively. Even then, Windows 11 started emulating x64 applications back in 2021. Meanwhile, FortiClient's beta 8.0 release only enables a limited set of features for Arm64-based processors. Arm64EC is Microsoft's answer to the compatibility problem. It's an Arm application binary interface (ABI) that follows "x64 software conventions, including calling convention, stack usage, data structure layout, and preprocessor definitions." It's why Office on Arm can load x64 add-ins, as it makes it possible for native Arm code and emulated x64 code to coexist within the same process. Even on the HP OmniBook, its driver package has most of its user-mode components in both Arm64 and Arm64EC versions. Microsoft also says most of the operating system code loaded by an emulated x64 application is compiled as Arm64EC. It gets even more complex than that, with some x64 software, including game overlays, DRM, and security tools, hooking Windows by patching the first few instructions of a system function. To maintain compatibility, Arm64EC uses what Microsoft calls a "fast-forward sequence," which is a small x64 stub that "passes for a legitimate x64 function" before going to the real Arm64EC implementation. These stubs are enabled by default for exported Arm64EC functions. In other words, Windows on Arm can present fake x64 instructions to software inspecting its functions, even though the actual code runs natively on Arm. Windows on Arm will even report an emulated CPU to some applications. For example, Microsoft says that "GetNativeSystemInfo also returns emulated processor details when run from an app under emulation," so that software expecting an x86 processor can keep working. I actually observed this in Cyberpunk, where the "CPU model" is simply listed as "Virtual CPU @ 4.00GHz". On top of that, even memory management looks different. On the OmniBook, Windows on Arm used 4KB memory pages for native Arm64 processes, matching the page size used by x86 Windows. My Mac, though, uses 16KB pages natively while presenting 4KB pages to x86 applications running through Rosetta. There's nothing inherently wrong with 4KB pages on Arm, but it's another difference in approach: Apple preserves the x86 behaviour for translated processes, while Windows uses the same base page size for native and emulated applications. Microsoft has actually removed support for an architecture from Windows on Arm before, namely Aarch32, or 32-bit Arm. It did that in 2023, a year after Arm dropped native 32-bit support from the Cortex-A715. What's interesting is that my OmniBook still has SysWOW64 and Program Files (x86), because Windows still supports decades-old 32-bit x86 applications. Microsoft was willing to abandon its own 32-bit Arm app format, but not 32-bit x86. Apple had the same x86 assumptions, and it broke them Rosetta has an end date Source: Sydney Louw Butler / XDA Intel Macs had much of the same baggage that Microsoft is currently dealing with. In Apple's porting guide, it warned developers that "Assumptions you make for your code on Intel-based Mac computers may not always apply on Apple silicon," while covering topics such as memory ordering, page sizes, SSE and AVX intrinsics, and calling conventions. Windows on Arm deals with many of the same architectural differences, but the two companies approached the problem in very different ways. In 2019, before Apple even announced the transition, macOS Catalina dropped support for 32-bit apps, which later meant that Rosetta 2 only ever had to translate 64-bit code. Apple was also already in the processing of moving away from third-party kernel extensions, replacing many of their functions with frameworks such as DriverKit and NetworkExtension, meaning that VPN providers could use Apple's NetworkExtension framework rather than maintain their own kernel-mode network drivers. When the M1 rolled around, VPN vendors already had a native route provided by Apple to get up and running. Apple also refused to allow for anything similar to what Arm64EC can do. Rosetta's documentation states that "The system prevents you from mixing arm64 code and x86_64 code in the same process," which leaves applications depending on old x86 plugins two options: Run entirely through Rosetta Find another way to communicate with those plugins The C++ ABI for Arm Macs also follows Apple silicon conventions used by iOS, completely sidestepping the older Intel Mac ABI. Rosetta also has an expiry date looming, with general-purpose support set to continue "through macOS 27," with only limited functionality retained for older games afterward. It wasn't a painless experience for Apple users, though. With 32-bit applications dropped, many 32-bit-only games were no longer compatible with the platform. Boot Camp, which would require drivers for Apple silicon on Windows, disappeared too. Even professional software like Avid's Pro Tools took years to make the transition. There are still incompatibility quirks to do this day, like x86 Windows in Parallels remaining a "technology preview" that's limited to one virtual CPU, no USB support, and long boot times. Microsoft could have been just as aggressive, but its Windows compatibility promise is precisely why it hasn't. Back in 2003, long-time Microsoft engineer Raymond Chen wrote that "It takes only one incompatible program to sour an upgrade." And to be fair, if I relied on an old scanner or audio interface with an x86-only driver, I'd want Microsoft to keep that promise too. Between the two platforms, compatibility debt comes from different places. In the macOS world, Apple controls both the hardware and the software, giving developers a deadline to move to the new platform. Windows, though, has a huge collection of legacy applications and third-party drivers it needs to accommodate, including from companies that no longer exist. For what it's worth, the Windows NT core isn't fundamentally tied to x86, and it was designed for multiple architectures from the start. Windows to this day still reserves memory in 64KB chunks, even though pages are only 4KB, and according to Chen, that comes from the DEC Alpha, not x86. DEC Alpha, a RISC ISA, built addresses out of two 16-bit halves, and keeping allocations on 64KB boundaries meant Windows only ever had to patch one half when it moved a DLL in memory. New Arm platforms keep needing new versions of Windows Most x86 chips don't RTX Spark and Snapdragon X devices support Windows 11 26H1, which is a different version of Windows 11 than what's available to x86 devices. 26H1, according to Microsoft, "is based on a different Windows core than Windows 11, versions 24H2 and 25H2," and it's intended for "devices with silicon that requires such." It showed up in the Canary channel of Windows in November 2025 before reaching consumers in February 2026, while Intel's Panther Lake, launched early this year, works on existing Windows releases without needing a separate branch. It's not even the first time that this has happened. When the first wave of Snapdragon X laptops arrived, they shipped with Windows 11 24H2 before any other device got it, and the RTX Spark has scheduler optimisations, changes to memory-page handling for unified memory, new power-management support, and Prism tuning all from Microsoft. Microsoft's Principal Product Manager, Peter Dawoud, told Tom's Guide that "Windows kind of had to get all these subsystems right all at the same time," and the publication states that it took eight months of Microsoft and Nvidia engineers working together "from the silicon bootstrap level upward" before the first RTX Spark machine booted. This lines up with a DigiTimes report from July 2025, which suggested that the N1X (RTX Spark) had been delayed as a result of Microsoft's operating system roadmap alongside Nvidia's chip revisions and weak demand. The N1X was originally expected in the second half of 2025, while Windows 11 26H1, the release it eventually shipped with, came quite a while after that. Part of this comes from the Arm PC ecosystem, especially given that x86 PCs have had decades of platform standardisation behind them, and Arm SoCs often have platform-specific components that need dedicated support. That's also why installing Windows on Arm from generic installation media can still require device-specific drivers. Even Copilot+ features, which have nothing to do with x86 compatibility, are totally missing on RTX Spark machines at launch. Still, the point remains that Intel could launch Panther Lake on an existing Windows release, yet any recent Arm launch on Windows has required considerably more platform-specific work. Intel only has to get a bit better And it already has Arm has had a couple of advantages over x86, especially when it comes to PCs. Not only is it a more open platform than x86_64 is, but its perceived energy efficiency makes it an attractive option thanks to the fantastic battery life touted by Apple's MacBooks which arrived at the same time as the Arm transition. However, the energy efficiency gap is a lot smaller than it used to be, with Lunar Lake offering a big step up in that department. to want Arm on Windows was its promised efficiency advantage, but that gap is much smaller than it used to be. The Snapdragon X2 and Apple's M-series chips remain ahead, but the RTX Spark doesn't have much of an efficiency advantage over the latest x86 designs. Chip designers have been saying this for years; Chips and Cheese found that Zen 2's instruction fetch and decode path consumed around 0.5 to 6% more package power than its op cache path, and AMD's Jim Keller has argued that instruction sets "only matter a little bit." Efficiency depends on far more than the instruction set, including microarchitecture, manufacturing process, and memory design, and those are all areas where Intel can and has improved, even if Lunar Lake's on-package memory was only "a one-off." Intel dropped its x86S proposal in 2024, opting instead to, alongside AMD, preserve its own legacy. Both companies formed an x86 Ecosystem Advisory Group with Microsoft and other companies to focus on extending the architecture instead. Microsoft is making a lot of progress on the Arm front, with Easy Anti-Cheat, BattlEye, and Fortnite now working on Windows on Arm, though Nvidia says that EA's Javelin anti-cheat and Call of Duty won't arrive on the RTX Spark until 2027. Microsoft also says native Arm versions are available for applications accounting for 90% of user minutes, which measures the availability of native applications rather than how much time users actually spend running native code. At the same time, Arm has reached a record 15.3% share of client PCs in Q2 2026, according to Mercury Research figures, but the bulk of that share comes from Macs and Chromebooks. Both of those benefit from platform ecosystems with more centralised control over software and hardware requirements. Windows on Arm has come very far in a few years, to the point that hardware is no longer its biggest obstacle. However, Microsoft's approach to x86 compatibility, namely preservation in the name of compatibility, leaves the ball in the court of third-party developers to move the platform forward. Existing x86 applications typically run well enough through Prism that there's little incentive to build native applications, and kernel drivers and anti-cheat systems still need native support and driver signatures that vendors may not consider worth developing for a smaller market. In the meantime, Intel and AMD only need to keep narrowing Arm's efficiency advantage for x86 to remain the default. That's a much easier task than persuading thousands of software developers and hardware vendors to prioritise another architecture.