Windows RT browsers and the point of Windows RT

It's no surprise that Firefox and Chrome won't run as desktop browsers on Windows RT devices; Microsoft has been saying all along that x86 apps wouldn't run on Windows on ARM and it explicitly said there would be no third-party code on Windows RT when it announced the details of the platform back in February. That's no plugins for IE on the Windows RT desktop as well as no desktop Firefox and Chrome, and if Mozilla and Google didn't notice that at the time, it's tempting to ask whether they were paying attention. Equally though, you do have to pay attention to get Windows 8, Windows RT, WinRT and Metro straight and Microsoft's cone of silence on some aspects of Windows RT hasn’t always made that easy.

The desktop code that runs on Windows RT will be the Windows desktop and the tools that are "intrinsic" to Windows, which includes Internet Explorer (as well as a management agent, Explorer, control panel and so on), plus Office.

We don't know how many of the Win32 APIs are there on Windows RT, although we expect the answer is something like 'only the ones that Office and the intrinsic-to-Windows tools require' because anything else is a waste of space, the time it takes to port and the surface that has to be protected against threats. Microsoft has been working on making the Windows desktop run and run well on ARM for longer than the iPad has been on sale (there's a photograph of it on a phone with the data in the metadata). It would have been obvious early on that virtualizing existing Windows apps would only get you slow apps that chewed up battery life. And it probably became obvious while making IE and Windows 8 run well on ARM how much work it would take for anyone else to do that. Microsoft doesn't want Windows RT to become slow and battery hungry because of someone else's code running on the desktop. Either it blocks third party code or it gets into the business of testing and approving third-party code.

There's another platform that doesn't have any third-party browsers; iOS. You can't run Chrome on the iPad. You can't even use the full Safari in an iOS application; you don't get the JIT, which makes the performance of Web apps on iOS less than impressive compared to running the same page in the browser. WinRT gives anyone wanting a browser-based app the same hardware-accelerated performance as the browser, on Windows RT or Windows 8.

Is it different for Microsoft to say 'no third-party desktop code' than for Apple to say 'no other browsers on iOS' or RIM to say 'no third-party mail clients in BlackBerry App World'? The aim in all three cases seems to be about protecting the user experience. It sounds different for Windows because we know Windows as a general purpose operating system. But whether it has a keyboard or just a touch screen, a Windows RT device isn't a PC the way we know it today; it's an appliance - like an iPad. A more specialised, more limited-purpose device, sacrificing universal flexibility and power for performance, battery life and security. That's a trade that large numbers of users and developers have already been happy to make on iOS. It seems churlish to say it's OK for Apple but terrible when Microsoft does it, just because we're used to what Windows has always been.

I've been calling it an open question whether WinRT is a powerful enough framework to write a complete browser in, especially given the sandboxing model for security. We don't know if the question is settled because we don't know if Google or Mozilla have tried and failed, or decided that it's not worth trying; it may be simply too much work to be worthwhile and it's certainly more work than waving the threat of legal action. It doesn't mean Microsoft is wrong to lock down Windows RT the way it has. It means it's important to understand clearly what Windows RT is and what it's for. Mary Branscombe