MicrosoftはWinRTのプラットフォームの特徴を強化し、開発者やエンドユーザのへ導入を推し進めている。しかし、WinRTの"囲い込み"が強制する限界に関心が集まるにつれて、これらの特徴の代償が明らかになり始めた。
MozillaのBrian R. Bondy氏は3月にWindows 8のFirefoxの開発計画を発表し、"...従来のディスクトップアプリケーション、メトロアプリケーション、メトロスタイルを可能にするディスクトップブラウザ"という3つの種類のアプリケーションがあり得ることを明らかにした。"メトロスタイルを可能にするディスクトップブラウザを開発する"というMicrosoftのホワイトペーパーにはブラウザ開発者はどのようにWindows 8用のブラウザを開発するのかについて詳述している。
LuaJITの開発者であるMike Pall氏は5月にサードパーティのジャストインタイム(JIT)コンパイラは動作しないと記している。
"Windows 8/ARMが許しているのは個人開発者が開発したサンドボックス上で動作するアプリケーションです。これらのアプリケーションはWinRT APIにはアクセスできますが、WIN32 APIには完全にはアクセスできません。WIN32 APIは確かにW8ARM上に存在してます。しかし、Internet Explorerとシステムプロセスだけがアクセスできます。"
この制限の影響は大きい。Pall氏はLuaJITの開発に言及しているが、ほとんどのユーザに影響があるだろう。"... [WOAでは]LuaJIT(JITモードの)も、PyPyも、Javaもv8も動作しません。これはほんの数例です。同様にこれらに依存するソフトウエア(Scala, Clojure, JRuby)もこれらが組み込まれているソフトウエアも動作しません。"しかし、"... [WOA]上のInternet Explorerのプロセスには特権が与えられており、JavaScriptを高速にするためのJITコンパイラが動作します。"これによって、IEは他のブラウザよりも高速に動作できる。
最近ではEmbarcaderoのAllen Bauer氏が同社のコンパイラにをWinRT向けのネイティブコード生成機能を追加しようとしたときの障害物について語っている。
"ネイティブのDelphi & C++のコードをWinRT上でサポートできるように取り組んでいますが、現時点でのWinRTに関する問題点は、言語のRTLを実装しようとしている開発者が利用する必要のある、OSが提供するAPIの多くが、VC++ RTL DLLを使わないと利用できないということに起因しています。"
この問題に対するMicrosoftの公式的な見解は以前に公開されたSteven Sinofskyの記事だ。
"...WOAは仮想化やエミュレーションをサポートしません。既存のx86/64アプリケーションの移植や実行もサポートしません。さまざまな形態のエミュレーションをサポートするのはシステムの信頼性や予測可能性を担保するためのモダンな手法とは相容れません。また、既存のコードはWOAのプラットフォームに対して最適化されていません。仮想化されたり、エミュレートされたりするソフトウエアはバッテリーやCPUなどのシステムのリソースを許容できないくらい消費してしまいます。" [強調は引用者]
さらに事態を複雑にしているのはMicrosoftの資料の矛盾だ。前述のブラウザ開発がイドには“メトロスタイルを可能にするディスクトップブラウザ”はJITコンパイルが利用できる、と書いてある。このような状況では、WinRT上で既定の作り方でないJITベースのブラウザがどのような動きをするのか解らない。
業界全体を見れば、AppleのiOSをターゲットに開発するとき、開発者は開発上の制限を予想するようになったという歴史的な経緯がある。違いはMicrosoftが既存のディスクトップブラウザ開発コミュニティからサポートを得ようとしていることだ。歴史的に見れば、これらの開発者はこのような制限に慣れている。