Microsoft announced today at CES in Las Vegas that the next version of Windows will run on ARM as well as Intel CPUs. But why? The reason is that ARM CPUs have huge momentum in mobile computing, thanks to their low power consumption. Microsoft wants Windows to support System on a Chip (SoC) architectures such as NVIDIA’s Tegra 2, which has two ARM Cortex-A9 CPUs combined with an HD-capable graphics processor in a single package. In its press release, the company is careful not to upset established x86/x64 partners Intel and AMD too much, emphasising that Windows will run on SoC packages based on those CPUs as well.
It is an interesting announcement, but one that raises as many questions as answers. The first concerns Microsoft’s mobile strategy, with Windows now seeming to encroach on territory that you have thought belonged to its embedded operating system, Windows CE, which underlies both Windows Mobile and Windows Phone 7. With all its legacy APIs, full-blown Windows does not seem ideal for low-powered, resource-constrained mobile devices; yet the company seems set on bringing full Windows rather than something based on Windows Phone 7 to the emerging tablet market.
The second issue is that applications will need at least re-compiling, and in many cases some re-coding, in order to run on ARM CPUs. Microsoft says it will deliver Office for ARM:
Sinofsky: Microsoft Office is an important part of customers’ PC experience and ensuring it runs natively on ARM is a natural extension of our Windows commitment to SoC architectures.
Windows and Office alone is enough for a decent business device; but customers who buy Windows on ARM expecting their existing games or applications to run will be disappointed.
We have been here before. In the early days of Windows CE, devices ran a variety of processors such as MIPS or Hitachi SH3, and developers had to compile multiple binaries and create setups that installed the right one on each device. In an attempt to overcome the friction this created, Microsoft introduced the Common Executable Format (CEF) with Windows CE 3.0 in 2000. This was an intermediate language format which was translated to native code by a “translator” when it was installed onto a device.
It sounds a bit like .NET or Java; and it was indeed a forerunner of the .NET Common Language Runtime, which appeared in 2002. However, CEF never really caught on. Although it solved deployment issues, it introduced performance problems and was troublesome to debug. Most developers preferred to stick with true native code.
Today though .NET is mature; and we also have Silverlight, a cross-platform implementation of the .NET Framework combined with multimedia player and graphics framework. If Microsoft includes .NET and Silverlight in its ARM build of Windows, that would solve some of the deployment problems, especially for business devices. Many custom applications are built for .NET; and these would in principle run without any need to recompile, since a .NET executable is intermediate code which is compiled to native code at runtime, though any code which includes “platform invoke” calls to native APIs would not work.
It is surprising therefore that neither .NET nor Silverlight is mentioned in Windows president Steve Sinofsky’s Q&A about Windows on ARM. Still, we should not read too much into that. It would be madness if Microsoft did not support its .NET technologies on this new platform, would it not?