Firefox on Windows Metro on ARM


Windows 8 Metro is a beautiful computing environment. Unfortunately, it's very limited when it comes to certain kinds of raw power that we're all used from the last couple of decades of Windows operating systems. Metro and the WinRT APIs that power it are great for games and simple apps, and they provide developers with the tools to make those apps stunningly beautiful, but they lack the kind of power needed to drive sophisticated programs like Web browsers and office productivity applications.

Now, we know that Microsoft is shipping a powerful browser on Metro. Metro would be dead in the water without a really capable Microsoft browser. So how does Internet Explorer 10 provide a beautiful and powerful experience in the Metro environment? It's easy. IE 10 cheats.

As you can see from the diagram here, Internet Explorer 10 on Metro has special access to some very powerful APIs from over in Win32 land. Those APIs allow for IE to have modern capabilities like a Just In Time compiler (JIT). JITs make JavaScript really fast and without them, modern Web sites like Facebook, Twitter, and Gmail would be painfully slow for users, *unusably* slow.

So, IE 10 on Metro gets its good looks from the WinRT APIs but it gets critical pieces of its power from the Win32 APIs. That seems kind of smart, right? Cheating works in this case, doesn't it? So what's the problem there?

There's no problem for Windows 8 on Intel chips, where Microsoft lets other browsers do the same thing IE is doing. The problem is with Windows for ARM processors. Browsers on Windows for ARM chips do not get to do what IE is doing. Microsoft is giving its own Internet Explorer special privileges that no other Metro app, including other Metro browsers, are allowed.

If we built Firefox for Windows ARM Metro, we would not have access to those powerful Win32 APIs and so we would be at an extreme disadvantage when compared to IE 10 for Metro. We could build a beautiful Firefox that looked really nice on Metro, but Firefox would be so crippled in terms of power and speed that it's probably not worth it to even bother. No sane user would want to surf today's web and use today's modern websites with that kind of crippled browser.

Microsoft can solve this problem for Windows on ARM the exact same way they solved it for Windows on Intel. They can give third party browsers the same access they give Internet Explorer. This access is described by Microsoft in the whitepaper "Developing a Metro style enabled Desktop Browser" and it should apply to all of Windows regardless of the processor that Windows is running on. Not doing so ensures there will be no serious browser choice and competition for lots of Windows users and that's inconsistent with Microsoft's public commitments and legal responsibilities.


So, the REAL issue here is the weakness of WinRT APIs. We should be calling for Microsoft to improve these APIs so that full-featured browsers can be implemented in Metro. "Cheating" or "Hacking" with legacy Win32 APIs is not a good long term option at all.

Sam, that's not quite right. The WinRT is not deficient because Microsoft hasn't made it more powerful. It's deficient because Microsoft made it deficient.

Think of it like this: There's a big old Windows API that has every awesome function call you can make on Windows. Metro apps are limited to a small piece of that larger Windows API by a sandbox that all Metro apps must live in. If you're not in that sandbox, then you have access to the full Windows API.

The sandbox sub-set of the larger Windows API is called WinRT. It's an intentional sub-set. WinRT isn't some ground up re-write all new APIs. It's mostly just a re-branding of the subset of win32 that Microsoft wants to maintain going forward.

So, it's not a matter of Metro or winRT not having the API because Microsoft hasn't written it yet. The APIs browsers need are right there, they're just blocked by the sandbox.

Microsoft isn't going to add some new APIs to winRT/Metro to make it more powerful. WinRT/Metro is intentionally a subset of the larger API to explicitly make it less powerful.

This less powerful WinRT API is on purpose less powerful. It was work for Microsoft to limit Metro apps from talking to all those more powerful WIndows APIs but they did it because they want an easier to maintain and secure platform, even if that platform is less capable.

Have I explained that in a way that's understandable?

- A

Thanks for the reply. I am well aware of the fact that these restrictions are intentional. But my point was, the self-imposed restrictions are clearly not viable in the real world, because highly useful software like browsers and productivity apps can't be made without hacking into Win32 APIs.

What's the point then? If their intention is security, then it is going to be breached anyway as IE10 and 3rd party browsers will use those APIs.

Why not include them in WinRT in the first place when they're essential for building the most essential of apps -- which is the browser?

Otherwise, this is going to be a never-ending theme. After Mozilla, VLC may complain that they can't make a good media player with restricted APIs, after that Adobe will complain they can't make Photoshop for Windows on ARM.

Finally, I don't think WinRT is a proper subset of Win32 as you mentioned. Unlike, .Net which was a proper subset, WinRT is more independent. As far as I know, you can write native albeit restricted apps using WinRT.

A good technical analysis of Mike Pall, developer of luajit, can be found on
(see also the follow-ups).
The problem is there are no VirtualAlloc() and VirtualProtect() functions available in WinRT - this makes writing a JIT compiler impossible using WinRT.

Mike Pall admits there that WinRT blocks a few more APIs that browser writers need. But not being able to write a JIT compiler in WinRT has consequences for more types of software:

"For W8ARM there'll be no LuaJIT (in JIT mode), no PyPy, no Java,
no v8, just to name a few. Ditto for any software that relies on
them (Scala, Clojure, JRuby) or embeds them."

Thus the Mozilla foundation should find fellows to fight together against these API limitations since the limitations also concern non-browser-writers.

MS have been under serious pressure here in Europe about there monopolistic grip on the browser market and seems they are not taking their legal responsibilities as they should be.

"inconsistent with Microsoft's public commitments and legal responsibilities"

Two things:

a. I agree Microsoft should provide APIs to let other browsers get the same capabilities as IE10 as that IS beneficial to the public.

b. It is not inconsistent with Microsoft's legal responsibilities however. Microsoft has no monopoly, and comparatively very little market share, in the ARM computing market. Thus, Microsoft can bundle products as much as it wants in the ARM market (and it is both with IE10 and MS Office which will have access to Win32 APIs in WinRT that other developers will not). If anything Safari on iPad is a better example of not adhering to legal responsibilities where Safari is getting a market boost in the tablet market because of the iPad's majority market share.

Monthly Archives