Early bird prices are coming to an end soon... ⏰ Grab your tickets before January 17

This article was published on August 28, 2012

The old, yet new firestorm: Windows RT is restricted, limiting the performance and API access of certain apps


The old, yet new firestorm: Windows RT is restricted, limiting the performance and API access of certain apps

Before you read this post, go ahead and fire up this clip. Tab back to this post when you are all set. 

If you have been over to Reddit in the last few hours, the following post must have caught your attention: “With Windows 8 on ARM, alternate browsers will be no longer allowed to [compete] fairly with IE. Microsoft will slow down Javascript on other web browsers.” That’s Reddit gold, if you were curious, but I digress.

Another point: the content that is causing controversy is actually from May, making this all proverbial old news. But it matters, and so here we are.

The question, ‘what the hell is going on’ is pretty important in this case, and TNW is here to help. Let’s break down what the original post says, and then we’ll talk about why it matters, and exactly what is going on.

Windows 8/ARM only allows sandboxed apps from independent developers. These only have access to the WinRT API, but not the full WIN32 API. Yes, the WIN32 API _does_ exist on W8ARM, but only Internet Explorer and system processes get access to it.

The WinRT API does not offer the equivalent of VirtualAlloc() or VirtualProtect() with the ability to make code executable at runtime. But JIT compilers absolutely require this functionality, which means there’ll be NO INDEPENDENT JIT COMPILERS for W8ARM!

The Internet Explorer process on W8ARM has special privileges and is the only one allowed to run a JIT compiler to speed up JavaScript. No other browser will be able to compete on performance with IE on W8ARM.

To parse all of that just for you, TNW called in Brandon Leonardo, a developer, and friend of the blog, to break it down. Brandon, go:

According to the post, Windows RT is preventing apps from compiling Javascript down to native code. All browsers do this now because it runs much faster. Instead, non-IE browsers [on Windows RT] will have to run JavaScript code dynamically (read: slower).

The fact that IE has access to the APIs to do JIT compiling means that Microsoft knows this API is necessary for some apps.

To begin, this isn’t exactly surprising. Windows RT is locked down in a number of ways, such as the only way to install applications is through the Windows Store. This limits what can in fact run on Windows RT devices, as every app must first pass Microsoft’s app approval gauntlet.

Is this move by Microsoft, limiting certain APIs a, ahem, mean move? I’d say yes, but it’s not dissimilar to what Apple does with iOS, for example. So while this is sure to irk developers, Microsoft isn’t being uniquely annoying. That’s important to keep in mind.

Is this anticompetitive? No, for a very interesting pair of reasons, I think. Firstly, Windows has no tablet market share, and Windows RT will run (nearly exclusively) on tablets. Secondly, I suspect that Microsoft could make the legal argument that Windows RT is different enough from Windows 8 that the market share of the larger Windows install base should not be counted when the behavior of Windows RT is considered.

Microsoft declined to comment, pointing to a blog post concerning what was then called ‘Windows on ARM.’ To underscore how unsurprising it is that Windows RT has limitations, the following excerpts [bolding: TNW]:

As we announced and demonstrated at //build/ and other forums, WOA has all the WinRT capabilities present in the Windows Developer Preview, and all the tools and techniques that you can use to build new Metro style apps for x86/64 are available to developers to also target WOA. Developers can use our tools to create native C/C++ code for maximal performance and flexibility, in addition to the C#, XAML, VB, and HTML5 based tools, to target apps for WOA, so long as their code targets the WinRT API set. Additionally, developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services. The Windows Store can carry, distribute, and service both the ARM and x86/64 implementations of apps (should there be native code in the app requiring two distributions).

In other words, if there was a controversy about this, it’s old, somewhat passe, unsurprising, and I would argue, non-unique, given that what Microsoft is up to exists in other, far more popular mobile operating systems.

Come to your own conclusion, but you likely won’t need a pitchfork when you are done.

Top Image Credit: BUILDWindows

Get the TNW newsletter

Get the most important tech news in your inbox each week.

Also tagged with