Windows on ARM – some notes

Windows on ARM – some notes

This evening, in lieu of a transcript, I listened a few times to Steve Ballmer’s CES keynote – specifically around the 3:06:23 mark. Given my blog post yesterday, I was most curious as to whether I was correct that there would not be any x86 application compatibility for Windows running on ARM. Steve’s words are below, emphasis is mine:

“We are very excited about the full set of partners for the next version of Windows.
NVidia, Qualcomm and Texas Instruments are working on SoC designs based on the ARM architecture.
Intel and AMD will continue to innovate on the x86 platform, including the new low-powered SoC systems that will be fully supported by Windows and will include support for native x86 applications.”

To paraphrase the above, x86-based SoC systems will of course include x86 application support, but new ARM-based SoC systems will not provide any emulation support for native x86 applications. Applications and device drivers will have to be recompiled and/or rewritten to run on Windows on ARM.

This is very significant, as it is both a pro and a con. The pro is that legacy x86 applications not optimized for gesture won’t likely cross into ARM, and new applications will likely be written that both take advantage of the ARM processor, end-user scenarios anticipated for the device (not sitting at a keyboard using a mouse, running Lotus 1-2-3), and be designed for the small/mobile form factors we can anticipate. The con is of course that application compatibility is what made Windows what it is today – most major applications make the leap from version to version of Windows,  and Microsoft makes a concerted effort to ensure legacy application compatibility. If you have an ancient x86 app for Windows 7 that you love, it may not be waiting for you (but a new version or an entirely new app may be) when you get there. This is uncharted territory for Microsoft. I can recall major burps Windows has hit along the way – 95 (loss of some 16-bit apps and many devices), ME (loss of real-mode DOS apps, XP (loss of many more DOS apps and many devices), Vista (mostly loss of devices). But this will be the most major hiccup I can think of in terms of application compatibility. Honestly, I feel that is a mixed bag, and Windows on ARM shouldn’t be noted as a “it’s a stupid idea because…” as I think a new generation of apps, designed for the form factor, CPU, scenarios, and end-user needs will be far more valuable to Microsoft than 20 year old applications that don’t need any of the new functionality delivered by systems using the ARM SoC architecture. Another significant benefit to excluding emulation support for x86 on ARM is operating system size. In order to support x86 applications with an emulation layer, the operating system would likely need to be nearly twice the size of an ARM-only version.

As I alluded to yesterday, Windows on ARM is step 1 of 4 to building computers (tablet/slate or other) that can compete with the iPad. This first step is significant – but it shouldn’t be touted as a move that will make a Windows PC on ARM an immediate alternative/equivalent for a consumer considering an iPad or other ARM-based slate or ARM-based notebook. To do that, Microsoft has to do the three additional steps, below.

  1. Natively support Windows on the ARM (or low-powered x86 SoC) processor architecture (including streamlining the OS to minimize background services and processes that blow CPU time/battery life)
  2. Emphasize gesture-based APIs as an equal mode of interaction with Windows vs. mouse/stylus
  3. Work with OEM partners to come up with system designs that are feature/value competitive, unique, and that consumers fall in love with
  4. Evangelize and enable an ecosystem of gesture-based applications and games before the platform arrives
Comments are closed.