Windows on ARM x86 emulation from a Mac transition perspective

Microsoft’s Edge browser is available for Windows on ARM as is Microsoft Teams. On the other hand, as for Microsoft Office, the only version that will run on Windows on ARM is the 32-bit Intel x86 binary — there is no ARM version of Microsoft Office. This is a very confusing situation that puts into doubt the level of commitment that Microsoft has towards Windows on ARM. Certainly, if you were an independent developer with a Windows application, you would be very concerned about the long-term viability of the new platform, and if Microsoft was not optimising their own software, then you might think that you shouldn’t either.

As is often the case however, the reality is not that simple.

I recently discovered a series of tweets from Hari Pulapaka, Group manager at Microsoft that cleared up the issue for me. Microsoft provides Compiled Hybrid Portable Executable (CHPE) versions of their Office DLLs (Dynamic Linked Libraries) which are optimised for ARM, which means that Office running on Windows on ARM is a hybrid of emulated x86 code and native ARM code. Microsoft analysed which DLLs are most critical for performance and then provided ARM optimised CHPE versions for these, while leaving the remainder as is. As a result, even though a large portion of the application is still emulated x86 code, the final result is much faster than 100% emulation. This allows Microsoft to get the first version with satisfactory performance quickly out of the door, and then to gradually rewrite the whole application leading eventually to a fully optimised version.

UntitledImage

UntitledImage

This approach is not new. Back in the late 1980s and early 1990s when Apple was transitioning away from Motorola 68k CISC processors and towards PowerPC RISC, they also had to provide a smooth transition path through code emulation. What they came up with was a 68k emulator and with a scheme so that instead of rewriting the whole MacOS System 7.1 in PowerPC code from the start, they would identify the most time-critical parts and optimise only those. This allowed them to make a gradual transition. The first version that could run on PowerPC Macs was System 7.1.2 which was still mostly 68k code running on the emulator. By System 8.5, Apple had replaced most of the 68k code and the system no longer ran on 68k Macs. Unlike the PowerPC to Intel transition in 2006 where Apple already had a version of Mac OS X that was running natively on Intel (“a secret double life”) many years before as a backup,  MacOS System 7.1 was a legacy system that was introduced in 1984 and was not designed to be CPU agnostic. Therefore it was clear from the onset that fully rewriting the OS would take years and hence the gradual optimisation route made a lot of sense.

The Windows version of Office has its roots back in the 1990s and it comes from an era when writing CPU agnostic code was less important for personal computers. It also has a large ecosystem of plug-ins which may not work across difference CPU architectures. Therefore a full rewrite in ARM code would require a lot of engineering resources and would also break plug-ins, many of which may come from third-parties. On the other hand, the code for the Edge browser (a lot of which is was based on the open source Chromium project which is CPU agnostic) is much easier to fully recompile for ARM. The same goes for Microsoft Teams which is built on the cross-platform Electron environment. 

The Mac version of Office is in a very different situation compared to Windows. Although the Mac version actually predates Windows, the multiple CPU and OS transitions on the Mac have forced it to also go through fundamental rewrites. Also, the plug-in ecosystem is much, much smaller. Therefore, we can speculate that rewriting the Mac version for ARM is a much easier undertaking.

We are tempted to assume that the lack of a fully ARM-optimised version of Windows Office for ARM is proof that Microsoft is not committed to that platform. However the reality is much more complex. The difficulty of the optimisation task varies widely depending on multiple factors, and this is often the most important factor in the decision to do so or not. It is rarely a matter of commitment alone.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s