64-bit apps on Windows on Arm are a work in progress: some are native, many work well with the new 64-bit emulation, but others will have to wait for more support in insider builds of Windows.
When Microsoft first launched Windows 10 on Arm, it could only run 32-bit x86 apps in emulation. Microsoft told us their telemetry showed the bulk of the Windows applications customers wanted to run had 32-bit versions — especially the older apps where developers were unlikely to recompile them for Arm. But that didn’t cover all Windows applications by any means.
Many games are 64-bit, but Microsoft told us that games were ‘outside the target customer’ for initial devices. There are 32-bit versions of Adobe Photoshop, Illustrator, InDesign and Dreamweaver available, but these are from an older release (Creative Cloud 2018) and lack newer features.
SEE: Microsoft 365: A cheat sheet (free PDF) (TechRepublic)
CorelDRAW still has a 32-bit version, but the new AI-powered features only work in the 64-bit version. Many installers, even for 32-bit software, are also 64-bit.
64-bit emulation is coming to Windows on Arm to help with that. It’s still in insider builds, but test results are encouraging.
Tools to go 64-bit
Microsoft may have been hoping that many more developers would recompile applications as native Arm versions, because the reason they were 64-bit in the first place was often for performance reasons, so running them in emulation wouldn’t be ideal.
That means getting the language and framework support that developers need, and again that’s been a gradual process.
Chromium, the Chromium Embedded Framework, and Electron have been available for Windows on Arm since late 2019, with native Chromium builds arriving in early 2020. .NET 5 brought ARM64 support, but support for WPF and WinForms is very recent, arriving in the first preview of .NET 6. The full .NET 6 won’t be released until November 2021, and discussions about how long it will take to get WPF ARM64 support .NET 5 are still ongoing.
Microsoft’s acquisition of jClarity meant it took on the work of porting OpenJDK to Arm for Windows 10. Neither IIS or Go-lang is available yet, but Python and Rust have native builds. The OpenCL and OpenGL Compatibility Pack was initially developed to help Adobe bring native Photoshop — which relies heavily on GPU acceleration — to Windows 10 on Arm. There’s a preview version that supports other OpenCL and OpenGL apps, but it’s only for OpenCL 1.2 and earlier and OpenGL 3.3 and earlier.
But while developers have been quick to make their apps native for Apple’s M1 Arm devices, progress has been slower on Windows — even for Microsoft’s own apps. Office and Edge run natively, as does the Windows 10 (Bedrock) version of Minecraft, but not the original Java version (it needs a much later version of OpenGL). Visual Studio Code is only recently supported on Arm, Power Toys is still blocked by a number of dependencies) and there are currently no plans for a native Arm version of Visual Studio. Microsoft’s expectation is that developers will cross-compile from a more powerful x86 system rather than doing their development work on an Arm PC — although Clang developers have created a native compiler for Windows on Arm, which runs builds twice as fast as in emulation.
Adobe released an Arm version of Lightroom for Windows and M1 Macs in December, and there’ s a native ARM64 version of Photoshop in beta; the latest release adds some of the key tools like the spot healing brush and content-aware fill and move. But because you can’t run two versions of the Creative Cloud Desktop app and the beta requires version 5.3 or later (which will only install 64-bit applications), you can’t install older 32-bit Adobe applications to run in emulation alongside it — and designers typically use more than one Creative Cloud application in their workflow.
The standalone installer for the most recent x64 version of Photoshop also fails, due to system requirements, but we were able to install the 64-bit Creative Cloud 2019 Windows versions of several Adobe apps (including Photoshop) alongside the native Photoshop beta and they worked well with the new 64-bit emulation. Often, the most difficult thing is getting the 64-bit version: smart installers will often install the 32-bit version automatically, so you might need to find the 64-bit version and install that directly.
The state of 64-bit emulation
The way Windows emulates x86 applications in software on Arm is based on the way it emulates x86 applications using hardware instruction emulation on x64 PCs — the ‘Windows on Windows’ abstraction layer. WoW64 isn’t exactly the same on ARM64 (where it actually emulates both x86 and ARM32 applications, using XTAJIT.DLL and WOWARMW.DLL respectively, because a number of inbox Windows applications like the Store are still 32-bit on Arm), but as Microsoft told us at the time, adding x64 support would be more work and it’s taken some time.
The first Insider versions of x64 emulation came out at the end of 2020. At the time, Hari Pulapaka, principal group program manager of the Windows kernel team, indicated that the final version of 64-bit emulation should run apps as fast or — thanks to the larger address space available to 64-bit apps and the way 64-bit code uses registries — faster than 32-bit.
“In general, x86 and x64 emulated apps should be similar in performance, except for the larger address space. We are still early in our emulation and so not all the optimizations have been added for x64. it will come over the next few months,” Pulapaka said.
Similarly, x86 emulation has continued to improve; there are new optimisations that speed up some operations in .NET applications like TurboTax and Quicken currently in Insider builds. On third-generation Windows on Arm devices like Surface Pro X and Galaxy Book S, those specific instructions can be emulated twice as fast as before.
The x64 applications we tested on an original Surface Pro X mostly ran well, although some apps crashed or simply closed as soon as we opened them (and some crashed the first time but then worked happily). For best performance, run applications twice: the first time the code is being converted to run on Arm; the second time it’s running from the cache (and some further optimisation has been done by Windows while it’s cached, improving performance further).
New insider builds will add more ARM64 system DLLs, which will improve compatibility and allow more apps to run successfully, and we’ve already seen apps work that wouldn’t run in emulation earlier.
SEE: Software as a Service (SaaS): A cheat sheet (free PDF) (TechRepublic)
64-bit versions of Signal, Slack, Bluestacks, Power BI Desktop, GIMP, Photoshop and the Xbox app all installed and worked well. Apps that need the Uranium framework install and run but are on the slow side. Autodesk’s Sketchbook had excellent performance even for demanding drawing tools, but was prone to crashing; we had similar issues with Affinity Photo, which worked well except when it closed unexpectedly.
Other 64-bit applications had more problems. CorelDRAW and PHOTO-PAINT installed and opened, but then closed immediately. Camtasia installed as admin but crashed when we tried recording. Those are the kind of problems likely to be fixed quickly as new insider builds come out with the DLLs applications require. There are also applications like the Dropbox sync client that require native drivers that Dropbox hasn’t provided, so won’t work at all in emulation.
We compared the performance of 32-bit and 64-bit emulation for Photoshop, GIMP and Power BI Desktop on a variety of tasks (although we weren’t always able to find the same version of the software). For common editing tasks, the 32-bit version of Photoshop running in emulation was often very slightly faster than the native 64-bit and emulated 64-bit versions, which had very similar performance: since both are in beta and haven’t been fully optimised that’s not unexpected, but the difference was usually between an effect taking two seconds and three seconds to finalise, and many common editing tasks completed instantaneously in both versions. The native version had a clear advantage on a complex sequence of tasks like a panorama photomerge: it was over twice as fast as the 32-bit version, and four times as fast as the 64-bit version in emulation.
Similarly, simple photo editing was a little faster in the 32-bit version of GIMP than in the 64-bit version until we ran more complex scripted actions, when the 64-bit emulation was two to four times faster.
Power BI Desktop was also slightly faster at loading reports and importing data from Excel when running in 32-bit emulation, although 64-bit emulation performance improved significantly with the latest insider build of Windows. Microsoft is clearly working hard at extending and optimising 64-bit emulation on Arm.
Microsoft announced its plans to bring Windows Server to Arm long before it came out with Windows for Arm laptops. It’s been used to run internal Azure infrastructure like storage, indexing and search where low-power, low-cost hardware and compute efficiency are particularly important. Things may have been delayed by server motherboard suppliers delaying or cancelling projects, but Microsoft has tested Windows Server on Arm silicon from Ampere Altra, Fujitsu and Marvell ThunderX2 for Azure, and Marvell said in 2019 that its Arm portfolio is in use for ‘internal, production-level servers’.
At the 2020 Arm DevSummit, technical fellow Arun Kishan from the Windows kernel team said that Microsoft was also exploring using Windows Server on ARM64 for VM hosting services and working with Arm on SystemReady certification for servers, which would include running Windows Server, “bringing them one step closer to enabling deployment in Microsoft Azure”.
That’s not to say full-fledged Windows Server on Arm is necessarily just around the corner, but the 64-bit emulation would be critical for Arm server workloads customers that would want to run, and may be another reason for Microsoft to add it to the Windows client.
Arm server in Azure will also fill in a critical missing piece for developers targeting Windows 10 on Arm: the ability to build a CI/CD (Continuous Integration/Continuous Deployment) system with a tool like Azure Pipelines, so they can easily test and roll out bug fixes and new code.
Developers need to be able to work directly on Arm devices for testing says Ed Vielmetti, who runs the Works On ARM ecosystem project at Equinix. Works On Arm provides open-source projects with Arm infrastructure — including Go, Node.js and several Python libraries — to help developers get their code working on Arm, so it can run in data centres.
“As soon as you can do native builds and native testing, you want to start doing that. You get a lot more fidelity in the test environment by testing on the real thing. And if you can convince a developer to use the target architecture as their daily driver, then you can get all sorts of things fixed because they’ll fix them up in sheer stubbornness and frustration,” Vielmetti said.
Several open-source projects are interested in porting their code to Windows, Vielmetti told us, but they want to run on Windows Server as well as desktop Windows; that’s not yet available for Arm. They also need Arm VMs in the cloud so they can do their testing at scale. That’s blocking NodeJS and tools like GitHub Desktop that depend on it.
“If you’re developing an operating system or language, or some sort of complex library that’s in motion, it’s really important to have enough infrastructure in place so that you can not only build your software once for distribution, but build it continuously as it evolves and changes over time,” said Vielmetti.
“The problem with code at scale is not just one lone developer writing code that they compile on their own machine and publish; it’s a horde of developers all contributing across a variety of platforms, with tests that are largely automated.”
And that automated testing needs cloud infrastructure with, in this case, Arm VMs.
“The availability of cloud infrastructure is transformative because you can start to support projects that have rates of change faster than what desktop hardware can handle,” Vielmetti explained. “Without that sort of full access to that supply of compute it’s really hard to imagine big projects having very much luck maintaining any sort of release cadence. If you’re trying to develop a complex system, how quickly I can turn around a new version and smoke test it really makes a big difference. In the absence of that ecosystem, Windows developers have a harder time getting that virtuous cycle of ‘build, test, try it out’ going.”
Hopefully, when Azure Pipelines does eventually get Arm VMs that will unblock a lot of developers to bring code to Windows on Arm. In the meantime, the emulation is steadily improving to support a broader — if not complete — range of software.