What Windows 11 means for Windows on Arm, and why it will bring more big name apps

Although the devices are typically thin and light PCs you can easily use as a tablet–and the demo of the new touch features in Windows 11 was done on an Arm-based Surface Pro X 2–the idea of Windows on Arm is that it’s “just Windows” that happens to be running on a Snapdragon Arm processor. It gets longer battery life but also does everything Windows normally does, including running the full range of software (and being deployed through Autopilot or Group Policy, managed through Microsoft Endpoint Manager or Configuration Manager and updated through Windows Update for Business or Windows Software Update Services).

Microsoft signalled the importance of compatibility for Windows on Arm last year by adding it to the App Assure program and turning on 64-bit emulation in Insider builds. But with Windows 11, the push is to get more developers to update their apps to run natively on Arm–especially applications where third-party plugins and addons are important.

SEE: Windows 11 cheat sheet: Everything you need to know (free PDF) (TechRepublic)

A more chipper CHPE

To bring their Windows apps to Arm natively, developers need a range of tools, from support in Visual Studio, compilers and frameworks (increasingly available) to cheap developer hardware for testing natively (the Snapdragon Developer Kit is expected later this summer) to cloud VMs for testing at scale (that will probably need a Windows Server Arm build and is something several open source projects are still waiting for).

But it’s not always possible to recompile an entire application at once, and sometimes there’s more than just the core app to think about. Applications like Office and Photoshop have third-party plugins that can be just as important to customers as the main program and those might not get moved over to Arm by their individual developers.

Windows 10 on Arm uses a system called CHPE, compiled hybrid portable executable files, which are specially compiled ARM64 code that can be called by x86 code without having to go back and forth between 32-bit and 64-bit data types and Intel and Arm conventions all the time. That delivers good performance and lets plugins that haven’t been migrated to Arm work with applications that have, but CHPE is complex to build and while Office uses it, it wasn’t available to third-party developers. It was also designed for the 32-bit emulation Windows on Arm originally supported.

With Windows 11, CHPE is replaced by ARM64EC (Emulation Compatible). This superset of ARM64 still allows developers to combine Arm and Intel code–this time for 64-bit as well as 32-bit code–so developers can port their own code piece by piece. If there’s a library, framework or other dependency they need that’s not yet available for ARM64, they don’t have to leave all their code running in emulation. Not all code needs the performance speedup of running natively; developers can do the work of porting the code that does and leave the non-CPU intensive code, like the user interface, running in emulation until they need or want to port it.

But the big change is that plugins will work with ARM64EC code whether they’re ported to ARM64 or not, and that’s no longer limited to Office. Adobe, Corel, Autodesk and all the other software creators whose programs have third-party plugins that users rely on can now port their apps to Windows on Arm without losing those extras (and they can put them in the new, more flexible Microsoft Store). Initially they need the preview version of Visual Studio and to be using Visual C++, but other compilers will be able to support ARM64EC when Microsoft documents more of the details.

SEE: Windows evolves: Windows 11, and the future of Windows 10 (TechRepublic) 

Apps using ARM64EC code don’t see anything special in Windows–they use the normal Program Files and Registry. And, according to Pedro Justo from the Windows on Arm team, who wrote on LinkedIn that “code compiled for ARM64EC runs at native speed, with virtually the same efficiency” so developers aren’t losing the benefits of porting to Arm, but they get the convenience of interoperating with existing x86 and x64 code.

Office is switching from CHPE to ARM64EC for its 64-bit ARM version so x64 plugins will work with it, and Windows 11 already uses ARM64EC for system DLLs so that x64 apps running in emulation will get system code that runs at native speed.

(If you look at those with developer tools, they’re marked not as ARM64EC but ARM64X; we think that refers to the whole X64 emulation system in Windows on Arm, which ARM64EC is one part of.)

No more Snapdragon 835 support

It’s not yet clear how much of this work will come to Windows 10 Arm devices, but hybrid ARM64X DLLs are already in the Insider builds with 64-bit emulation; it’s just that Microsoft hadn’t explained much about how they worked until the Windows 11 announcement.  

The vast majority of Windows on Arm devices will be able to run Windows 11. But although Microsoft tells us it won’t have an Arm version of the PC Health Check compatibility tool it offered and then withdrew until closer to launch, the earliest models like the HP Envy x2 used the Snapdragon 835, which we already know is not supported.

That’s not because Windows 11 is now only a 64-bit operating system. 32-bit Arm support was for Windows IoT rather than Windows on Arm PCs and the 835 is an ARM64 system, but it has an earlier version of the Arm system architecture (v8.0) which doesn’t include some of the Arm v8.1 instructions that make emulation and virtualisation faster.

SEE: Photos: Windows 11 features you need to know (TechRepublic)

Any user mode ARM32 apps should still run in Windows 11. But some Microsoft apps that have been running in emulation–notably Teams and OneDrive–are now moving to be native ARM64 apps, which will improve battery life and performance (as well as proving that Microsoft is actually taking Windows on Arm seriously).

Windows 10 already takes advantage of the Arm v8.1 memory improvements to speed up emulation on devices with Snapdragon 850 and 8cx devices, but being able to improve Hyper-V performance will be increasingly important for good performance on Windows 11, which turns on several virtualisation-based security features.

That will also matter for features like the Windows Subsystem for Android, which is based on Intel’s Bridge Technology (formerly known as Houdini); a binary translator for running Android Arm apps (on Intel and AMD) that’s in some ways similar to how x86 apps run in Windows on Arm. Microsoft confirmed to us that “this experience will work across processors,” and the Intel Bridge Technology can itself run in emulation if Intel doesn’t port it to Arm. However, Microsoft is encouraging developers to bundle Intel versions of code in the Android APK to get better performance on Windows 11 PCs, and it’s not clear if WSA on Arm will run that APK code in emulation or just load the existing Arm app code. Either way, virtualisation performance will be key to a good experience.

So far, though, none of the Snapdragon platforms used for Windows on Arm implement Arm v8.3, which supports nested virtualisation and adds pointer authentication to prevent the kind of Return-Oriented Programming attacks that Windows shadow stack uses Intel CET feature to protect against.

Perhaps with the acquisition of Nuvia, Snapdragon will start implementing more recent Arm instruction sets; there are significant security features in Arm v8.5 and 9, as well as instructions that will speed up machine learning models, which are showing up in more applications.

This may be a chicken and egg situation. With more of the important 64-bit Windows applications, ideally with native performance thanks to ARM64EC, Windows on Arm will be a more interesting platform for PC makers and the users who buy devices, which could push Qualcomm into offering better hardware options. But even on existing hardware with the very first Windows Insider builds, we’re seeing a small but welcome boost in Windows performance on Arm that will only get better with more native and hybrid applications.

Also see