The first Windows on Arm PCs have gone on sale from HP, and at Microsoft’s recent Build developer conference the company offered more details about the nuts and bolts of making code run well on Qualcomm-based Windows devices. This also told us a little more about how this platform will develop in the future.

The big questions with Windows on Arm are how many existing Windows applications these devices can run without any changes, and how well those applications perform, because the code is running in emulation. To make the performance of the applications you’re working with as good as possible while still keeping the battery life advantages of Arm, Microsoft is taking advantage of the big.LITTLE architecture of the Snapdragon 835 SOC (which has four powerful, power-hungry cores and four slower cores) to prioritise the parts of applications you interact with. This is called heterogeneous kernel scheduling and the manager of the Windows kernel team, Hari Pulapaka explained how it speeds up applications in Windows on Arm.

SEE: IT hardware procurement policy (Tech Pro Research)

“The cores are all the same processor, but the big core runs faster and uses more power; the little core runs slower but has the advantage of using less battery power.” Not only can the same piece of code run on either the big or little core, but it can also move between cores without any interruption or performance hit.

“When you run an application, the kernel schedules the threads of the application that you interact with on the big, fast cores,” said Pulapaka. “But the threads in the background, like services, that aren’t related to user activity are kicked out and migrated to run on the small core. When you’re launching Outlook, every thread in Outlook runs on the big core. But your services, your indexer, your background tasks, all these ancillary threads like indexing — they run on the little core. That way they don’t consume a lot of power, but the things you care about are snappy and instantaneous. This is how you get good battery life and good user experience.”

Crucially, Microsoft is also expanding the options for developers to get 64-bit software running in Windows on Arm, as well as software like antivirus or CD-burning tools that needs to install its own drivers. The lack of 64-bit support was one of the major limitations initially. Now, although the changes won’t help with older code that developers aren’t interested in updating, developers who need the larger memory available to a 64-bit application — or who just want to take advantage of the newer, more efficient Arm instruction set — can recompile UWP, x86 and x64 code to Arm64 using Visual Studio 15.8 Preview 1, so they run as native code rather than in emulation.

“The Arm64 code generation is slightly better than Arm32 because the Arm64 instruction set has more registers and the instructions support more operations,” Pulapaka noted. Moving to 64-bit code is usually done when apps need more memory, but in this case it also gives them better CPU performance, even if they were already running as native Arm code.

The Windows kernel team has been working with some popular open-source apps and drivers that didn’t initially work on the Qualcomm devices, like OpenVPN and the VLC media player (which turns out to be one of the most widely used applications in Windows, according to Microsoft’s telemetry). In both cases, very little — if any — code had to be changed to get them running. Both projects plan to add Windows on Arm support based on this work.

Shim it up

For existing x86 apps that don’t have a developer to change them, most will run in emulation without any problem, but some will install and then not run. That happened to my favourite utility, ClipMate (a handy clipboard manager that hasn’t had an update in years but still works well). Changing one of the built-in compatibility settings fixed the problem, and the setting will be turned on by default for the app in future Windows Insider builds, along with the compatibility settings for all the other apps Microsoft has been testing. These kinds of compatibility ‘shims‘ have been in Windows for years to help apps that relied on particular Windows behaviour work on newer versions.

Some applications — like Microsoft Office — can mix x86 and Arm code using CHPE (Compiled Hybrid Portable Executable) DLLs with Arm64 code but 32-bit x86 interfaces; as a result, hundreds of third-party Office add-ins that expect Office to be an x86 application will work with Office on Arm too. Other applications like Photoshop and CorelDRAW have third-party plugins as well, so will Microsoft allow software developers like Adobe to convert DLLs to CHPE? Maybe, but if it does happen it won’t be for some time. “Right now, the emulation is such an early project that we haven’t opened up CHPE yet,” Pulapaka said at Build. But the way CHPE works might change over time.

The long-term solution is to get developers to recompile to Arm64, rather than to stick with emulation — in the same way that you can still run 16-bit applications in Windows, but the vast majority are 32-bit code now. Arun Kisha, head of the software engineering team building Windows on Arm, emphasized that CHPE isn’t relevant to many applications. “It’s for an x86 application that needs to load in a third-party ecosystem of plugins; to retain compatibility with that you still have to be an x86 app, and you can streamline portions of the code that you control. That’s essentially the office scenario. In any other scenario, you’re better off porting the whole app to Arm, because there are still some overheads with CHPE — it’s not like pure native software.” But for the applications that do need it, if the platform becomes popular it might be a possibility.

Power or performance?

The other big question that remains about Windows on Arm is what it’s for. Although devices come with Windows 10 S, many users will take the free upgrade to Windows 10 Pro, which has features like domain join, or running WinML machine-learning models using DirectX 12 on the GPU. It can even run the Windows Subsystem for Linux (WSL). Canonical has already submitted the WSL version of Ubuntu 18.04 to the Windows Store (it’s an Arm64 build, not an x86 version that would run in emulation).

But if Arm is powerful enough for internet services like Cloudflare to run on, and powerful enough for Azure to start using Windows Server running on Arm chips in the data centre for demanding, highly parallel workloads like indexing, search, storage, databases and machine learning, why is Microsoft is still pitching Windows on Arm devices for browsing, email, creating Office documents and watching Netflix rather than for running complex applications like Visual Studio or Photoshop?

It’s not clear if those more demanding Windows applications don’t parallelise well enough to take advantage of the multiple threads and cores (and the heterogeneous scheduling) that give Arm its advantage, or if Microsoft — or OEMs like HP and Asus — are just being tentative about how these Arm devices compete with Intel and AMD, and so are focusing on ultraportable systems that compete with tablets and Chromebooks. Newer Qualcomm chipsets like the Snapdragon 845 might also enable beefier devices, but Microsoft is only concentrating on the 835 at the moment.

That might change in the future, Kisha suggested — whether it’s the 845 or another Arm chip supplier. “Dedicated support for other silicon co-processors is being evaluated across the board,” he noted. “As time goes on, as the product space develops, we’ll look at our options. We will evaluate over time — as usage patterns change, as hardware changes — what makes sense. So I wouldn’t say it’s out of the question.”

But that will also depend on how Windows on Arm devices sell. If the thin, light devices with long battery life do well, it’s more likely that we’ll see a wider range of hardware in the future.

Also see