第三方开发者可将 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 这种形式的限制。

查看英文原文： Can 3rd Party Developers Bring JIT and Compilers to WinRT?