Windows on ARM: The Challenges
- The Portable Kernel
- The Legacy Problem
- Emulation to the Rescue
- .NET and ARM
- Will It Work?
Microsoft recently announced that Windows 8, which (going by previous Windows release schedules) is due out some time in the next one to ten years, is going to run on ARM. Before the announcement, lots of people were claiming it was impossible. Afterwards, many of the same people were saying that it won't work. In this article, we'll take a look at Microsoft's history of supporting other platforms and some of the challenges that they face in the future.
For a long time, Microsoft Windows was very closely associated with the Intel architecture. The portmanteau wintel was common, referring to the duopoly of Microsoft and Intel in the PC market. In recent years, Intel's ties with Microsoft have weakened. They now provide the CPUs for Macs and sponsor a lot of work in the Linux ecosystem, so it's not surprising that Microsoft would look at alternatives.
The Portable Kernel
Supporting other architectures isn't exactly new for Microsoft. The Windows NT kernel was intended to be portable. The NT name comes from the Intel 860 CPU, which was the original target. Although Windows NT was expected to ship for x86 initially, the development team worked on a different architecture first to make sure that there were no x86isms in the final code.
In some ways, this is a shame. There are several features that were introduced with the 386 that could have provided a cleaner OS design if they'd been used, at the cost of portability.
Microsoft did ship versions of Windows NT for other operating systems. I have a Windows NT 4.0 CD, which says on the label that it runs on MIPS, PowerPC, and Alpha, as well as x86.
The only one of these that saw much use was the Alpha port. This had an advantage because, at the time, the Alpha was undisputed performance king. In 1997, you could buy a 553MHz Alpha, when the fastest CPU from Intel was a 300MHz Pentium II, and was slower clock-for-clock.
Since NT 4, Microsoft has only supported one non-x86 architecture with Windows NT. Windows Server 2003 and 2008 both shipped with Itanium versions. Given the minuscule sales of Itanium systems, it is doubtful that Microsoft made much, if any, money from this port.
The XBox 360, running on a PowerPC architecture, also uses an NT-based kernel, although it's not clear how much code this shares with the desktop-Windows version.
Supporting a new architecture in any kernel is always more than a straight recompile, but it's much easier when the kernel has already been ported once. Microsoft already has experience targeting ARM with the WinCE kernel and it may even be possible to reuse some of this code.
About the only parts of a kernel that are dependent on the CPU are the page tables and context switching logic, and the interface to external hardware. This is typically not much codea few thousand lines.
The big effort when supporting a new architecture is typically the required device drivers. Supporting ARM doesn't mean supporting a PC motherboard with an ARM CPU plugged in instead of the x86 chip; it means supporting all of the hardware on a diverse array of ARM systems-on-chip (SoC). These can differ widely, not just in obvious ways like different DSPs or GPUs, but also in fundamental things like timers and interrupt controllers. Most likely, Microsoft will expect SoC manufacturers to provide drivers for their hardware. How well this works depends on how many third parties they can get on board. At the very least, I'd expect nVidia to work with them to get Tegra 2 supported.