Microsoft ARM Ambitions May Repeat Old Mistakes

Way back in Ye Olden Days of 2012, Microsoft tried something unusual: It released a Surface tablet (dubbed the “Surface RT”) with the same ARM architecture that powers mobile devices. This was a spectacular deviation from Microsoft’s traditional embrace of PCs powered by Intel’s x86 architecture, but Microsoft felt that Windows needed to compete toe-to-toe against Apple’s iPad and various Google Android tablets.

The Surface RT—and Microsoft’s ARM dreams—proved such a spectacular failure that the company needed to take a $900 million write-down on unsold units (which it dryly termed “Surface RT inventory adjustments” in a later filing). But if you thought that was the end of the story, you’d be wrong: Almost eight years after that debacle, Microsoft is planning to take another run at ARM.

According to The Verge, a new, ARM-based surface will provide better battery life, solid performance, and the potential for slimmer hardware (thanks to ARM chips running cooler than their x86 siblings). “Getting ARM right simply opens up so many more opportunities for Microsoft than sticking with Intel does. It’s not just making thinner tablets that could go up against the iPad,” wrote The Verge’s Dieter Bohn. “It’s completely different form factors—that dual-screen device, for example, would be a good candidate.”

But that ignores one of the key reasons why the ARM-based Surfaces failed back in 2012: backward compatibility. Windows RT couldn’t run any programs built for x86 processors, and developers were slow to build ARM-compatible equivalents for an untested platform. No business would buy hardware it couldn’t run its mission-critical apps on—and business spending is a huge portion of Microsoft’s bottom line.

(Microsoft has made several attempts at overcoming the “app gap” between Windows and ARM-based ecosystems such as Android and iOS. A few years after the Surface RT pancaked, it launched Project Astoria, which would have allowed developers to port Android apps directly to Windows; that died. There’s also Windows Bridge for iOS, but developers haven’t rushed to convert their iOS apps to a Windows-friendly format in massive numbers.)

Developers like to make money. They like having an audience for their products. Given the constraints on their budgets and time, they don’t like having to build or rebuild apps for new platforms that might not pan out in terms of revenue and audience. Microsoft sometimes seems to have trouble with this equation—Windows Phone, for example, failed in part because it couldn’t convince enough developers to build unique, cool apps for the platform (or spend the time porting their solid apps from iOS or Android to Windows Phone).

If Microsoft goes down the ARM road again, it hopefully learned from the mistakes of its past. With no deep reservoir of x86 apps to rely on, Microsoft will need to encourage developers to jump onboard—and do a better job of it than the last time around.

5 Responses to “Microsoft ARM Ambitions May Repeat Old Mistakes”

  1. You may have forgotten that, this time, microsoft has an Apple-style binary translation package, that allows ARM cpus to run legacy WIN32 apps via JIT recompilation. There’s a performance impact of course, but that’s clearly, as in Apple’s case, a stop gap solution.

    • Nick Kolakowski

      Do you think that’s enough to overcome a developer enthusiasm gap? Part of Microsoft’s problem has been trying to convince developers to even give these platforms (ARM Windows, Windows Phone, etc.) any kind of look.

      • As you correctly stated, developers want to have a machine sold in numbers large enough to be worth the investment. Binary translation gives you the chance to sell the machines. The average user will not care nor know if they are running Chrome x86 on a core m3, atom z5 or an ARM cpu, as long as it works. If (ok, big if) the device reaches decent volume sales, then developers will come to optimize of it.

  2. Shirley Dulcey

    It’s easier to port applications to ARM now. Visual Studio supports it, so for most programs it’s just a matter of installing ARM support in your copy of Studio and changing the build options. ARM support comes automatically for the few UWP applications that exist.

    The built-in binary translation will take care of your legacy applications that you can’t get redone for ARM. It only supports 32 bit programs, but that covers all the cases where the source code isn’t available for a rebuild or the developer has closed down. It won’t be as fast as native builds but it should be good enough to cover most needs.

    Microsoft could take one more step to accelerate the acceptance of ARM versions of Windows: require ARM compatibility as a condition for getting Windows certification of new applications and updated versions of old ones.