Microsoft has greatly promoted the features of the WinRT platform to developers and end-users as it seeks to encourage its adoption. However the price of these features has begun to be fully realized as concerns linger over the boundaries that WinRT's "walled garden" enforces.
Mozilla's Brian R. Bondy previously announced in March their plan to develop Firefox for Windows 8, and how this project revealed 3 classes of applications: "...classic desktop applications, Metro applications, and Metro style enabled desktop browsers." Microsoft's whitepaper, "Developing a Metro style enabled Desktop Browser", goes into detail on how developer's may target their browser for Windows 8.
LuaJIT developer Mike Pall noted in May that the way Windows 8 on ARM (WOA) is constituted it is not possible for third-party just-in-time (JIT) compilers to exist:
"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 ramifications of this limitation is wide-reaching. While Pall's immediate concern is the development of LuaJIT, this will affect nearly all users as "... for For [WOA] 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." However, "... the Internet Explorer process on [WOA] has special privileges and is the only one allowed to run a JIT compiler to speed up JavaScript." This could give IE an inherent speed advantage over every other browser.
The latest development is from Embarcadero's Allen Bauer who has found a roadblock in his work adding native code generation for the WinRT platform to his company's compilers:
"We are very keen on supporting WinRT with native Delphi & C++ code. Right now, the issues surrounding the WinRT space center around the fact that many OS-supplied APIs which are required by anyone implementing their own language RTL are actually off-limits unless you're the VC++ RTL DLL."
The closest to an official Microsoft response remains the previously released article by Steven Sinofsky that states:
"...WOA will not support any type of virtualization or emulation approach, and will not enable existing x86/64 applications to be ported or run. Supporting various forms of emulation runs counter to the goal of delivering a product that takes a modern approach to system reliability and predictability—by definition, existing code has not been optimized for the platform the way WOA has. Virtualized or emulated software will consume system resources, including battery life and CPU, at unacceptable levels." [Emphasis added]
To further complicate matters is the apparent contradiction in Microsoft's materials. The aforementioned browser development guide states that a “Metro style enabled desktop browser” – of which there can be only one active system wide at a time– will be allowed to use JIT compiling. It is not clear in these situations how the WinRT platform would react when faced with a JIT-based browser built was no longer the default.
In observation of the industry as a whole, it should be noted that developers have historically come to expect restrictions on their development when targeting Apple's iOS platform. The difference here is that Microsoft is attempting to obtain the support of their existing desktop-based developer community, and historically these developers are not used to these types of limitations.