Was forbidding desktop applications on Windows RT the correct move?

Every day, someone bugs me at work about the news reports relating to how the Surface RT was not the success Microsoft had hoped it would be.  And Asus had the same conclusion.   I tell them Surface RT was a great piece of hardware.  It had the misfortune of not being able to run desktop apps.

But what about if Windows RT (Windows ARM) had allowed desktop applications (that have been recompiled to use the ARM instruction set) to run instead of just the ones that Microsoft had allowed (i.e. Office, and several built in apps, such as notepad, calculator, and some remote debugging tools).

I’ve been following the threads on xda developers on how the digital signing of desktop apps was circumvented to allow desktop apps to bypass this check completely, and in effect, open it up for desktop development.

Apart from the exploit, how was this possible at a tools level?  Well, if we go back to //build (in 2011), and look at the Beta version of Visual Studio 2012, you’ll notice something interesting: a complete version of MFC for ARM (including static lib files).  You’ll also notice that several key Windows SDK libraries were excluded (such as common controls, etc), making these MFC libraries more difficult to take advantage of.

The question remains: why would they have included MFC if they hadn’t planned on allowing developers to make desktop apps targeting ARM? My theory is that the original plan was to allow development of desktop apps for ARM, but at some point it was decided that desktop apps should be controlled and their creation only made available to Microsoft themselves.  Hence, when the first developer preview came out at //build there were still remnants of the original plans.

After this first build, subsequent builds removed the MFC libraries that were included in that first Beta.

So coming back to the original question: was forbidding desktop apps on ARM the correct move? At the surface level (pardon the pun) it looks to be a good decision.  the WinRT (Metro) environment provided for store apps, is tightly controlled, and therefore can have a better impact on battery life, potential viruses, app revenue, etc.  But it does stifle competition.  Look at VLC for ARM right now.  They can’t make a desktop app so have been forced to go to kickstarter to fund a Windows 8 (Metro) version of their app.  It’s still under development due to the tight controls over which APIs are allowed in WinRT apps. It’ll be interesting to see when, if ever, they release something.

Imagine the ability to have Chrome or Firefox for your Surface RT? Good thing?  I’m not sure.  Or your favorite app, which only needs to be recompiled for ARM using Visual Studio, and released directly from the software developer rather than through the store.  Good thing?  Hmm, the pros and cons are hard to weigh.  If you are starting from a zero ecosystem and trying to build it up, maybe desktop apps would have been a good thing.  But on the other hand it might have caused developers to focus less on the Windows Store apps and more on their legacy desktop apps.

But judging from the developer buy-in for WinRT (Windows Store apps), it’s a moot point.  The fact is, there hasn’t been enough buy-in.  And this is the key to success of the ecosystem, having developers risk getting no revenue from a store app, vs continuing with their legacy desktop apps on Intel only.  If they had allowed desktop apps on ARM, it’s possible more of those developers would be more excited about Windows RT.