Making it easier for developers to port applications to Arm at their own pace without losing the convenience of emulation should make Windows on Arm more believable.
While the devices are generally thin, light PCs that you can easily use as a tablet – and the demonstration of new Windows 11 touch features was done on an Arm-based Surface Pro X 2 – the idea of Windows on Arm. is that it’s “just Windows” running on a Snapdragon Arm processor. It extends battery life, but also does everything Windows normally does, including running the full suite of software (and deploying it 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 signaled the importance of compatibility for Windows on Arm last year by adding it to the App Assure program and enabling 64-bit emulation in Insider builds. But with Windows 11, the goal is to get more developers to update their apps to run natively on Arm, especially apps where third-party plugins and add-ons are important. .
SEE: Windows 11 Cheat Sheet: Everything You Need to Know (Free PDF) (TechRepublic)
A CHPE plus shredder
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 inexpensive development hardware. for native testing (the Snapdragon SDK is expected later this summer) to cloud VMs for large-scale testing (this will likely require a Windows Server Arm version and this is something several open source projects are still waiting for ).
But it is not always possible to recompile an entire application at once, and sometimes you have to think of more than the main application. Applications like Office and Photoshop have third-party plugins which may be just as important to customers as the main program and these may not be transferred 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 and Intel data types. and Arm conventions all the time. This offers good performance and allows plugins that weren’t migrated to Arm to work with applications that did, but CHPE is complex to build and although Office used the technology it was not available. for third-party developers. It was also designed for the initially supported Windows on Arm 32-bit emulation.
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 and 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 isn’t available for ARM64 yet, they don’t have to let all of their code run in emulation. Not all code needs the performance acceleration of a native runtime; developers can do the work of porting the code that does and let non-CPU-intensive code, like the user interface, run in emulation until they need or want to port it.
But the big change is that plugins will work with ARM64EC code whether ported to ARM64 or not, and it’s not just limited to Office anymore. Adobe, Corel, Autodesk and all the other software makers 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 Microsoft Store. more flexible). Initially, they need the preview version of Visual Studio and use Visual C ++, but other compilers may support ARM64EC when Microsoft documents more details.
SEE: Windows evolves: Windows 11, and the future of Windows 10 (TechRepublic)
Applications using the ARM64EC code don’t see anything special in Windows – they use the normal program and registry files. And, according to Pedro Justo of the Windows on Arm team, who wrote on LinkedIn that “the code compiled for ARM64EC runs at native speed, with virtually the same efficiency” so developers don’t lose the benefits of porting. to Arm, but they get the convenience of interoperating with existing x86 and x64 code.
Office is moving from CHPE to ARM64EC for its 64-bit ARM version so that x64 plugins will work with it, and Windows 11 already uses ARM64EC for system DLLs so that x64 applications running in emulation get system code that runs at native speed .
(If you look at the ones with developer tools, they’re not marked as ARM64EC but ARM64X; we think this refers to the entire X64 emulation system in Windows on Arm, of which ARM64EC is a part.)
No more Snapdragon 835 support
It’s not yet clear how much of this work will come to Windows 10 Arm devices, but ARM64X hybrid DLLs are already in Insider builds with 64-bit emulation; it’s just that Microsoft hadn’t explained much how they worked until the announcement of Windows 11.
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 was offering, then withdrew until at launch, the first models the HP Envy x2 used the Snapdragon 835, which we already know is not supported.
Just because Windows 11 is no longer just a 64-bit operating system. Support for 32-bit Arm 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 does not include not some of the Arm v8. 1 instructions that speed up emulation and virtualization.
SEE: Photos: Windows 11 features you need to know (TechRepublic)
All user-mode ARM32 apps should still run on Windows 11. But some Microsoft apps that used to run in emulation, including Teams and OneDrive, now become native ARM64 apps, which will improve the lifespan and performance of battery (while also proving that Microsoft does take Windows on Arm seriously).
Windows 10 is already taking advantage of Arm v8.1 memory enhancements 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 enables several virtualization-based security features.
This will also be important for features like the Windows Subsystem for Android, based on Intel’s Bridge technology (formerly known as Houdini); a binary translator for running Android Arm apps (on Intel and AMD) which is in some ways similar to how x86 apps run in Windows on Arm. Microsoft has confirmed to us that “this experiment will work on all processors,” and Intel Bridge technology itself can emulate if Intel does not port it to Arm. However, Microsoft encourages developers to bundle versions of Intel code into the Android APK to get better performance on Windows 11 PCs, and it’s unclear whether WSA on Arm will run this APK code in emulation or just load the. existing Arm application code. Either way, virtualization performance will be the key to a good experience.
So far, however, none of the Snapdragon platforms used for Windows on Arm implement Arm v8.3, which supports nested virtualization and adds pointer authentication to prevent the type of back-end programming attacks. which the Windows phantom battery uses the Intel CET feature to protect against. .
Perhaps with the acquisition of Nuvia, Snapdragon will begin implementing newer Arm instruction sets; There are important security features in Arm v8.5 and 9, as well as instructions that will speed up machine learning models, which are appearing in more applications.
It can be a chicken and egg situation. With more important 64-bit Windows applications, ideally with native performance thanks to ARM64EC, Windows on Arm will be a more attractive platform for PC makers and users who buy devices, which could push Qualcomm to offer more. better hardware options. But even on existing hardware with the very first versions of Windows Insider, we’re seeing a modest but welcome increase in Windows performance on Arm, which will only get better with more native and hybrid apps.