Mozilla发布可让WebAssembly在网页之外执行的标准系统界面WASI

新一代网页格式WebAssembly提供极佳的执行效率，让浏览器也能够执行像是游戏或是Photoshop这类重量级网页应用程序，而Mozilla要进一步扩充WebAssembly的可移植性，让WebAssembly应用程序顺利跨出浏览器，因此开始推动WebAssembly系统界面WASI，使WebAssembly能以更直觉的方式与系统核心沟通。

由于WebAssembly是一个概念机器（Conceptual Machine）而非物理机器的组合语言，因此可以在不同的平台上执行，而要让WebAssembly在浏览器之外，还能在不同的操作系统上执行，需要一个概念操作系统的系统界面，而这正是Mozilla致力制定WebAssembly系统界面WASI的原因，以扩展WebAssembly到更多的平台。

一般应用程序可以透过系统呼叫，请求操作系统核心执行特定操作，在多数的装置上，这是程式码可以存取系统资源的唯一方法，而由于多数开发语言都有标准函示库，因此开发者也不需要知道不同操作系统的实作，只要知道怎么使用界面就行了，当程式码在编译的时候，工具炼会依照程式码目标系统，选择需要的界面实作，而这个实作则取决于操作系统API的函式，每个操作系统有所区别，像是对Windows机器就会使用Windows API，为Mac或Linux机器编译就会使用POSIX。

但这样的模式却无法套用到WebAssembly上，在WebAssembly编译阶段，系统仍然不知道应用程序的目标操作系统，因此也无法在标准函式库的WebAssembly实作，使用单一操作系统的界面。虽然现在WebAssembly已经可以在浏览器之外执行，但是却使用非正规的方法。

Emscripten编译工具在网页上模拟操作系统界面POSIX，让开发人员特以使用C标准函式库中的函式，为此Emscripten创建了C标准函式库的实作，实作分为两部分，一部分编译成WebAssembly模组，另一部分则以JavaScript中介程式码实作，而JavaScript中介程式码会呼叫浏览器与操作系统沟通。

要在没有浏览器的情况下执行WebAssembly，执行的Runtime需要实作JavaScript中介程式码中的函式，Mozilla提到，这些JavaScript中介程式码的界面并非为标准而设计，甚至还对外公开。因此这只能作为暂时的解法，为了WebAssembly生态系统的长久发展，需要寻求更根本的解决方案。

为了要保持WebAssembly的可移植性以及安全性，Mozilla提出了WebAssembly系统界面解决方案，建构一套模组化的标准界面，而这项工作从最基础的wasi-core开始，wasi-core将包含所有应用程序需要的基础，包括档案、网络连接、时间以及随机数字等POSIX功能，来允许应用程序执行开启、关闭、读取或是写入档案等工作。

但wasi-core也不会涵盖POSIX的所有部分，像是程序概念就不会完全映射到WebAssembly上，而每个WebAssembly引擎也不需要支援像是fork这样的程序操作。Mozilla表示，模组化的好处在于让利基平台可以只使用适合的WASI部分，像是Rust就能直接在标准函式库使用wasi-core，对C和C++而言，则可以使用C标准函式库实作wasi-sysroot。Mozilla希望Clang这类编译器也可以与WASI API相容，像Rust编译器和Emscripten等工具链，把WASI纳入系统实作中。

Mozilla表示，wasi-core是WebAssembly正式跨出网页的第一步，并为其生态系统建立了良好的基础，而在wasi-core完全标准化之后，还需要解决异步I/O、档案监控与档案锁定等工作。