第三方开发者可将JIT和编译器引入WinRT吗？

微软在向开发者和终端用户大力推广WinRT平台的特性，以鼓励更多人采用它。但是，随着人们对WinRT “围墙花园”所强加的限制的关注，这些特性的代价逐渐被大家所全面认识。

Mozilla的Brian R. Bondy在三月份曾宣布过为Windows8开发Firefox的计划，以及该项目如何展示三类应用：“……经典桌面应用，Metro应用以及支持Metro风格的桌面浏览器”。微软的白皮书《开发支持Metro风格的桌面浏览器》详细讲述了开发者怎样将他们的浏览器移植到Windows8中。

LuaJIT的开发者Mike Pall在5月份表示，ARM版Windows8（WOA或Windows 8 on ARM）的组成架构不支持第三方JIT（Just-in-time）编译器：

“Windows8/ARM只支持在沙箱（Sandbox）内运行独立开发者的应用。这些应用只能访问WinRT API，无法访问所有WIN32 API。是的，WIN32 API在W8ARM上 的确存在，但只有IE和系统进程可以访问”

该限制的影响广泛。Pall关注的是JuaJIT的开发，但几乎所有用户都受到影响：“……对于[WOA]，将没有LuaJIT（JIT模式下）， 没有PyPy，没有java，没有v8等等，以及依赖或内嵌它们的任何软件（Scala、Clojure、Jruby）”。然而，“……[WOA]版IE 具有特殊权限，是唯一被允许运行JIT编译器以加速JavaScript的软件”。对于任何其他浏览器，IE将有天然的速度优势。

Embarcadero的Allen Bauer带来了最新的发展，他在工作中发现，在WinRT平台上将本地代码生成能力添加到其公司的编译器中是行不通的：

“我们非常希望在WinRT上支持本地Delphi&C++代码。问题是，任何人实现其语言的运行库（RTL）时都需要使用一些操作系统提供的API，而事实上WinRT却限制这些API的使用，除非VC++运行库”。

最新的微软官方响应依旧延续了Steven Sinofsky以前发表的文章的论调：

“…… WOA将不会支持任何虚拟化或模拟化手段，不支持现有x86/64应用的移植或运行。支持各种形式的模拟器有碍于提供系统可靠性及可预测性的产品发布，设计即是如此。现有代码没有像WOA那样针对该平台进行优化。虚拟化或模拟化软件耗费太多的系统资源，包括电池寿命和CPU。”

让事情更复杂的是微软材料中存在明显的自相矛盾。上述的浏览器开发指南声称“支持Metro风格的桌面浏览器”允许使用JIT编译，系统中同时只有这类浏览器的一个活动版本。这种情况下，当面对基于JIT的浏览器不再是默认配置时，WinRT平台会如何应对尚不明确。

对整个业界的观察中，可以注意到，开发者历来会接受苹果iOS平台对他们开发的限制。而不同的是，微软试图得到他们现存桌面开发者社区的支持，而这些开发者历来不喜欢类似WinRT这种形式的限制。