In January of 2011, I wrote my first suppositions about “Windows 8” and the ARM processor architecture. Though we now know the version of Windows that will land on ARM will be called Windows RT, and the Windows 8 name will be reserved for editions of the operating system that will run on x86/x64 processors.

In that blog post early last year, I stated:

Microsoft has never sustained Windows on any platform besides x86. 
What would make Windows on ARM succeed where others have failed?

This is really, really important. I want to emphasize that Windows RT may do here what other versions of Windows haven’t been able to do before, which is what I refer to as “achieving architectural escape velocity“. It may. Let me explain what I mean by architectural escape velocity.

MS-DOS and Windows originated on, and grew up on, the 16-bit Intel x86 architecture. Windows 95 began the consumer step to 32-bit Intel x86 support, while Windows NT started with 32-bit support natively – but Windows NT didn’t start on the x86 processor.
I mentioned this last year as well. Windows NT was originally developed on the Intel i860 processor (a RISC-based chip) first, with the intention of ensuring platform portability. But the i860 was never supported by a released version of Windows. So it was – Windows NT, with it’s portable architecture, was born with that same x86 birthmark.

The consumer versions of Microsoft’s legacy operating systems – from MS-DOS 1.0 to Windows ME – were never available for any other architecture other than Intel’s x86.

The Windows NT-based operating system has been ported to 8 architectures in its lifetime:

• Intel i860 – Pre Windows NT 3.1 (never released)
• Intel x86 – Windows NT 3.1-Windows 8 (1993-present)
• DEC Alpha – Windows NT 3.5-4.0 (1994-2000)
• MIPS – Windows NT 3.5-4.0 (1994-2000)
• PowerPC – Windows NT 3.51-4.0 (1995-2000)
• Intel Itanium – Windows XP – Windows Server 2008 R2 (2001-2009)
• AMD/Intel x64 processor architecture – Windows Server 2003 SP1-Windows Server 2008 R2 (2005-present)
• ARM SoC Processor Architecture – Windows 8 (not yet released)

Of these 8 platforms, only two (other than x86 itself) ever supported running x86 code on them

• DEC Alpha – Windows NT 3.5-4.0 (1994-2000)
• AMD/Intel x64 processor architecture – Windows Server 2003 SP1-Windows Server 2008 R2

The DEC Alpha, though it was a 64-bit processor, ran 32-bit Windows. It used a layer called FX!32 to run x86 Win32 applications without requiring recompilation or modification. The x64 architecture, though it does not support legacy 16-bit applications or 32-bit drivers, runs 32-bit Windows applications directly without requiring recompilation or any advanced emulation layer. There is a thin virtualization layer that enables this.

So through 7 architectures (not including ARM yet), only two survived. x86 – the first architecture Windows NT shipped for, and the commodity architecture that it has survived on through the death of so many others, and x64 – an architecture that is fundamentally an extension of x86 to support 64-bit computing. Semantically, we could argue that only one survived.

But what about the Mac? What about Apple? Almost every major epoch of Apple has involved a different processor architecture.

• Apple II – 6502 processor (1977-1993)
• IIe card for Mac – 65C02 processor (1991-1995)
• Macintosh – Motorola 680×0 –  (1984-1994)
• Macintosh – PowerPC – (1994-2006)
• Macintosh – x86-64 (2006-present)
• iOS Devices – ARM – (2007-present

However, there are a couple of interesting things here that differ dramatically when we compare how Windows supported different architectures versus how Apple did.

1. When Apple added a new architecture, the old one was completely transitioned out, even if it took some time. The one (perhaps temporary) exception to this is the current world where Apple makes devices/systems using both ARM-based and Intel processors.
2. When a new architecture was added, there was a way to run legacy applications – at least for a time.

• From the IIe to 68K Mac there was the IIe card
• From the 68K Mac to PowerPC Mac there was a complex emulation layer – which actually enabled Apple to keep large bits of the OS in 68K compiled code, without having rebuilt everything immediately.
• From PowerPC Macs running Mac OS 9 to PowerPC Macs running Mac OS X, there was Classic, which enabled both 68K and legacy OS 9 applications to run on the Mac.
• From PowerPC Macs running Mac OS X to x86-64 Macs running Mac OS X, there was Rosetta, which enabled legacy Mac OS X apps only compiled for PowerPC to run (but Classic/68K support was dropped).

NextStep – from which Mac OS X was derived, was written originally for the 680×0 processor architecture, but was also ported to the SPARC, PA-RISC, and most importantly, Intel x86 architecture before Apple acquired it.

So why did I throw Apple into a discussion about Windows? Because I found a few things fascinating as I pondered these two separate courses of events the other day:

1. Apple has made at least 4 “burn the ships” architecture shifts. Microsoft has never burned the x86 ship. In fact, x86/x64 have burned every other potential Windows NT ship that came along, by offering rapidly evolving, “low”-cost systems, with extremely high application compatibility – unmodified.
2. Apple – though maligned for hosing customers, actually provided better application compatibility with each of these platform shifts. The counterpoint is that they needed to, since they burned the old platform.
3. Apple was able to achieve architectural escape velocity by burning the previous architecture, yet supporting it as a cantilever in the new system.

Windows customers never bought systems in other architectures other than x86/x64. This was likely, depending on the architecture, due to:

1. High cost of alternative processor systems vis-à-vis their performance (Itanium and Alpha being great examples here)
2. Lack of 16-bit Windows or 32-bit Win32 application compatibility
3. Lack of native applications.

iOS is the unusual exception here. Born on a device with no application platform (the original iPhone), there was no possible way to (or value to) carry legacy Mac applications over to the iPhone, even once it had an application platform. However, what we can see is Apple playing the same compatibility card when the original iPad shipped. Though they looked atrocious, the iPad could run iPhone apps at native or 2x resolution. In a sense, a nod towards the old model of using the old/established platform to cantilever the new one.

When we look then at Windows RT and Windows 8, they provide an unusual set of design choices. Windows 8 will, again, not burn the x86-x64 ship. In fact, I think that the threat of Windows on ARM processors taking hold due to Windows RT may have Intel showing us some amazingly low-powered x86/x64 tablets later this year that could really limit how broadly Windows RT takes hold, but may mean much broader adoption of Windows 8 tablets that can run legacy Win32 applications as needed. Given that Windows RT won’t support legacy Win32 applications other than the OS fundamentals (Explorer, etc) and the Office applications that are included in it by default (Word, Excel, PowerPoint, and OneNote – note, no Outlook), Windows RT is still seemingly positioned as a “companion” device to a Windows 8 PC. The only cross-platform API set is then WinRT, an entirely new API set built into Windows 8/Windows RT, which enables the creation of cross-platform apps – but won’t run on older versions of Windows – but it is the sole “bridge” that binds these two platforms together.

If Windows RT succeeds, it will be due to the merits of the platform, the cost/power/weight/form factor of the devices, and the successful build-out of the Windows App Store. I don’t believe that Windows RT is intended to supplant Windows 8 on x86/x64. It is intended to complement it.