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、檔案監控與檔案鎖定等工作。