This week's Windows Weekly broadcast spends about 20 minutes (from 2:00 to just past 20:00) on the topic of Microsoft banning competing browsers from Windows on ARM.

Paul and Mary Joe do a really good job of explaining things. The one thing I'd like to highlight, and Paul touches on this, is that were talking about more than just IE on the classic desktop on Windows on ARM. We're also talking about being disadvantaged in the Metro environment. That's actually the larger of the two issues.

Internet Explorer is basically one browser with two front ends. The back-end is basically the same in classic and Metro and it has access to special Windows APIs that no other app on Metro has access to. That means that this is not just a problem of other browsers being excluded from the classic desktop on Windows on ARM, but other browsers are also at an extreme disadvantage on Metro compared to IE.

IE on Metro has access to the full win32 API, unlike any other Metro style app -- including third party browsers. Without that access, it's simply impossible for other browsers to compete with IE on Metro. No other browser would be able to have a modern JavaScript engine -- Microsoft's JavaScript engine would be 10-30 times faster than any other browser's because IE has privileges on Metro that let it mark memory as executable (something you need for a JIT to make JS fast). No other browser would be able to compete with IE in terms of stability and security because IE has access to APIs for creating extra processes and brokering between those processes so it can sandbox tabs and plug-ins and generally build a more secure product. No other browser on Metro would have access to those APIs.

So, when Paul and Mary Jo talk about how Microsoft could make things right with third parties by just not having classic desktop IE on Windows on ARM, yes, that would be a small step, but it's not the classic desktop environment we actually want. No one wants to spend time in that environment on a Windows on ARM machine. What we want, and what IE has, is access to the classic win32 APIs that power the classic desktop while in Metro mode.

On x86, we had the same exact problem. Firefox on Metro did not have access to the same APIs as IE on Metro. Microsoft solved the problem by creating a new category of Windows 8 program called Metro style enabled desktop browsers. But what Microsoft was really doing there was saying "Your Metro browser can use your classic browser's back-end, which has access to the full win32 API" which is precisely what IE was doing.

Microsoft should provide the same exception on Windows on ARM and allow browsers on Metro to access the full win32 API just like IE does.

update check out that awesome 2004 Firefox 1.0 New York Times poster behind Paul :-)

This Has Worked Well

| 5 Comments

"The U.S. antitrust ruling requires that Microsoft disclose all of the interfaces internal to Windows called by 'middleware' within the operating system, such as the browser, the media player, and so forth. In this way, competitors in these categories will know that they can plug into Windows to get the services in the same way that these built-in Windows features do. This has worked well, and Microsoft will continue to disclose these interfaces even after the U.S. antitrust ruling expires."

Let's start with these.

  1. Open Protocols. Microsoft commits that all the protocols in [Windows] that are used by any other Microsoft product will be made openly available to the developer community in a non-discriminatory fashion. These Open Protocols may include protocols that implement industry standards.

  2. Open APIs. Microsoft commits that all the APIs in [Windows] that are used by any other Microsoft product will be made openly available to the developer community in a non-discriminatory fashion. These Open APIs may include APIs that implement industry standards.

  3. Open Access. Microsoft will publish its documentation for these Open Protocols and Open APIs on its website so that all developers will have the benefit of this technical information in a manner that takes advantage of the nature of open discussion on the web. Microsoft will not require developers to obtain a license, or to pay a royalty or other fee, to have access to all this information....

via Microsoft Interoperability Principles

This is the single best article I've read all week on the topic. If you read this a couple of times, you will walk away with a better understanding of this issue than pretty much everyone you know, including many of the people writing about it.

Third Party Browsers Blocked on Windows 8 for ARM? by Kshitij Sobti

This is another really good article that helps to explain some of the "What about Apple? Aren't they doing the same thing?" questions I've been hearing.

Mozilla on new browser brouhaha: Microsoft, Apple different cases by Gregg Keizer

Software Development

| 4 Comments
Senate Judiciary Committee staffers plan to take a look at allegations that Microsoft has made it difficult for competing Web browsers to run on a certain version of Windows, an aide to Antitrust subcommittee Chairman Herb Kohl (D-Wis.) told The Hill Thursday.

That's an interesting development.

The New Bing is Nice

| No Comments

The new Bing is really nice. They caught up with Google on algorithmic search last year, IMO (at least in the US.) This update catches them up in "take direct action" department and pushes well ahead in the social integration area. I think that team really nailed it with social integration. Good for them.

continued from Firefox on Windows on ARM - Microsoft Says No

It's not precisely "running a browser in Classic" that matters for Windows on ARM. It's that running a browser in Classic is the only way that Microsoft has allowed us to get access to the APIs that a browser needs to deliver modern capabilities and performance in Classic AND Metro.

A browser running exclusively in Metro does not have the APIs necessary to compete with IE or any other modern browser.

On x86, Microsoft has given browser vendors the same privileges and APIs that IE uses. They have not done this on ARM.

That's why Windows Classic on ARM matters.

update: I've been asked by a couple of people on Twitter and email to elaborate. Let me give it a try.

On x86 Windows 8 PCs, there are three kinds of software programs.

First, there are Classic programs that are basically the same as they are Windows 7. Because of the rich win32 API available in Classic, these kinds of programs can be really powerful (or not,) but they can only operate in the Classic environment and cannot use any of the cool new features available in Metro and they cannot be run in Metro. In this category you can think of programs like Adobe Photoshop or Microsoft Word.

Second, there are Metro apps that are touch-focused, simpler, but have rich interactions between themselves and Metro and other Metro apps. These apps have access to some cool new Metro features but they live in a Metro sandbox and cannot use any of the more powerful features available from the Classic win32 environment -- APIs necessary for building a modern browser. In this category you can find apps like Angry Birds, Microsoft Stocks, or Hulu.

Third, there are Metro style desktop enabled browsers. These are programs that straddle Classic and Metro. They have access to the underlying win32 API like Classic programs and they also have access to the cool new features of Metro. They can have a classic front end and a Metro front end but under the covers they're calling into both the Classic and Metro APIs. In this category you have Internet Explorer 10, Firefox, and likely other browsers including Chrome and Opera.

Microsoft has made it clear that the third category won't exist on Windows for ARM (unless you're Microsoft) and that neither will the first category (unless you're Microsoft.) That means that IE on ARM has access to win32 APIs -- even when it's running in Metro mode, but no other Metro browser has that same access. Without that access, no other browser has a prayer of being competitive with IE.

Happy to answer any questions in comments.

update 2: I've also been asked why Windows on ARM matters. It's for tablets, after all, and that's just a tiny sliver of the larger PC universe.

That's true today, but it's not going to be true next year and the year after and the year after. ARM will be migrating to laptop PCs and all-in-one PCs very quickly. If you read Microsoft's blog posts about Windows on ARM, you'll see that they expect ARM PCs to cover the whole spectrum. ARM chips are already being used in servers. This is not a tablet-only concern.

Microsoft is trying to lock out competing browsers when it comes to Windows running on ARM chips. IE is allowed there but not Firefox or Chrome or Opera or any other competitive browser. This is bad for the Web.

Here's what's going on. For Windows on X86, Microsoft is giving other browsers basically the same privileges it gives IE. It's not great that you don't get those privileges (certain API access) unless you're the default browser and I think that's deeply unfair (a post for later,) but at least we're able to build a competitive browser and ship it to Windows users on x86 chips.

But on ARM chips, Microsoft gives IE access special APIs absolutely necessary for building a modern browser that it won't give to other browsers so there's no way another browser can possibly compete with IE in terms of features or performance.

This is in direct violation of the promises they made to developers, users, and OEMs about browser choice in documents which mysteriously disappeared from Microsoft's site -- remember this? I sure do.

Here's a PDF of the pages that Microsoft disappeared in the run-up to their anti-choice decisions for the Windows OS running on ARM chips. Windows Principles - Empowering Choice, Opportunity, and Interoperability (PDF)


update: The Wall Street Journal has a blog post up titled Microsoft Accused of Hindering Firefox Browser and Stephen Shankland has posted Microsoft bans Firefox on ARM-based Windows, Mozilla says at CNET. The FT has also just posted Microsoft hit with complaint over Windows 8.

update 2:I've got more to say about this here.

Want to help make the Web a better place? Want to work with me?

I'm looking for a Senior Product Manager to help define the future of web browsing for half a billion Firefox users.

Mozilla pays well. We have great health benefits. And, honestly, how can you not want to work with me ;-)

I was marveling over the boot times I get on this Samsung Series 9 Windows laptop, somewhere between 8 and 10 seconds, when it occurred to me that my Andriod phone, a fairly high-end Samsung Galaxy Nexus, doesn't seem to boot that fast. So, I decided to time it.

First I reset the phone to factory defaults, just in case there was something in there slowing the startup. (Note, I didn't do this to my Windows laptop.) Then I timed three boot ups and averaged them.

The average time to the unlock screen was 26 seconds! That's almost three times as long as it takes to boot Windows 7 on this Series 9 laptop. A top of the line Android phone running the latest stock Google Android OS shouldn't take three times as long as that "pig of an OS" Windows to boot on a medium performance laptop, right?

Now, I don't re-boot my phone or my laptop very often, so it's really the wake from sleep that matters and here the phone beats the laptop with a one second wake compared to a two to three second wake for the laptop. Still, phones need to boot faster :)