There has been quite a bit of recent discussion and hearsay about Windows on ARM processors – that is, a rumor that Microsoft is developing a version of Windows (full Windows, not CE/Windows Phone 7 – which already run on ARM)  that supports the low-powered ARM processor preferred for mobile devices today.

Windows NT, upon which all full versions of Windows today are based, was designed from day one to be a “portable” architecture. Though the Intel x86 (and the architecturally derived 64-bit AMD64/x64 platform) has always been and continues to be the principal architecture supported by Windows, it didn’t start out that way (the first architecture supported by NT wasn’t x86 – it was the Intel i860 RISC processor – explicitly to force a portable architecture).

Throughout it’s life, NT has supported quite a few non x86 architectures – but in the end, every one has been deprecated – even the Intel Itanium (IA64) architecture is now end-of-lifed – leaving x86 and it’s descendant x64 as the sole Windows architectures. Again.

It is surely possible that the Windows codebase could be ported to support the ARM architecture. But let’s stop for a second and asses what Windows on ARM would really mean. Assume Microsoft released a version of Windows 7 (say at the same time as Service Pack 2) or it simultaneously shipped Windows 8 for ARM at the same time it shipped for x86/x64 in the assumed Q4CY2012 timeframe. What would Microsoft really gain?

As many people say Microsoft should port ARM to Windows, I think it’s important to note what Microsoft would and would not gain by adding support for ARM. This list is not perfect, it is comprised of some fact and some opinion, and I welcome your feedback and will tune it accordingly. But I believe anyone saying, “Microsoft needs to port Windows to ARM” should carefully consider this maneuver. Microsoft has never sustained Windows on any platform besides x86. What would make Windows on ARM succeed where others have failed?

Truths of Windows on ARM

• Windows on ARM is possible. TRUE – Microsoft has ported the Windows codebase to RISC architectures before, and could surely do it again. The low power constraints of ARM provide a unique challenge, but it could be done. See the next point though; this is only part of the battle.
• Windows applications could be ported to ARM. TRUE – Though key applications and APIs are designed explicitly for the x86 or x64 architecture, it would not be insurmountable to port them to ARM – again, this still isn’t the most significant problem facing Microsoft to provide an iPad counterpoint – gesture-based navigation and low power consumption are.
• Windows on ARM could provide a desktop platform as well as a tablet platform. TRUE – certainly Windows optimized for tablets could run on desktops as well, and would likely provide a great thin client platform (as Windows CE and now Windows Embedded Compact have done for some time). Touch enablement may not be as logical here, though and a focus on thin clients would risk mindshare and potentially marketshare of Office users unless an ARM-based, gesture-focused version of Office was also available.

Fallacies of Windows on ARM

• Windows on ARM will provide a counter to the iPad. FALSE (technically) – Architecturally porting Windows is step one. Gesture-enabling the entire operating system and providing gesture-focused development APIs are step two. OEMs must then provide devices as compelling as or more compelling than the iPad, at a competitive price and with reasonable non-WiFi connectivity options (see the recent $100 Galaxy Tab price drop for an example here). Simultaneously, Microsoft would need to nurture an ISV application ecosystem in a way they have not in some time, and with urgency they haven’t really ever done – all while not randomizing the Windows Phone 7 platform or ISV ecosystem.
• Windows applications and games will work on Windows on ARM. FALSE – no way. Windows has used legacy application compatibility as a cantilever to induce upgrades from one version to the next. Not only is that not possible in this scenario, it becomes a liability. Every aspect of Windows and any application would need to assume that there may never be a mouse or physical keyboard attached to the system, and must focus on gesture-based navigation at all times – if it is to provide a true counterpoint to iOS. In addition, Microsoft would need to provide Flash and Silverlight for this platform, or full HTML5 in the browser in order to enable multimedia playback. If Microsoft included a full Flash runtime, it would need to be gesture enabled as well, and would likely encounter power consumption and/or performance issues. Android and other ARM-based platforms running Flash have been criticized for high power consumption, as have full Windows systems running on single-core Atom processors (simultaneously criticized for their performance – resulting in the need for dual-core Atom processors).
• Windows on ARM provides a significantly better solution than a gesture-enabled Windows running on Atom. False – though a power-optimized, gesture-enabled Windows with API support is hardly trivial – it is an easier task than porting Windows, and would result in legacy applications working – though that is potentially a detriment, not a benefit.
• Windows on ARM provides a significantly better solution than Windows CE or a “Windows Tablet 7” derived from Windows Phone 7 would. FALSE – Windows Phone 7 has shipped, and will be updated throughout 2011. It is gesture-enabled now, runs on ARM processors today, and supports gesture-enabled application development. Though no legacy x86 applications would be supported (I believe this actually to be a net benefit), it would be considerably easier to derive a Tablet/slate focused version from Windows Phone 7 than porting Windows.
• Devices for Windows would work with Windows on ARM. FALSE – no devices would make the shift. Though this has traditionally been a detriment to Windows (lack of application and device driver support precluded Windows XP for x64 from being widely adopted) this would actually be a net benefit if considering a competitor to iOS. You don’t want mice. You don’t want legacy keyboard, display drivers, or game controllers. Those are baggage. In a gesture-enabled Windows, the cut line needs to be clear, or customers won’t understand, and OEMs won’t “go big” with new platforms.