Introduction

Welcome to the WASIX documentation, your primary resource for understanding and working with this innovative extension to the WebAssembly System Interface (WASI).

Developed by the Wasmer team, WASIX is a transformative initiative designed to make WebAssembly (Wasm) more compatible with POSIX programs, enabling the seamless execution of more complex applications in both the browser and server environments. This documentation will provide you with an in-depth understanding of WASIX, its design philosophy, its capabilities, and its differences from WASI.

WASIX is more than just an extension; it's a pathway towards widespread adoption of WebAssembly. By filling in the critical missing POSIX features in WASI, WASIX allows developers to use WebAssembly as a universal target, eliminating the need to adapt their programs specifically for it.

This documentation is organized to provide comprehensive details on WASIX, from its basic concepts to more advanced features. You will learn about the WASIX toolchain, its runtime support, and the broad range of features it supports, including efficient multithreading, sockets, current directory support, subprocess spawning, TTY support, and more.

Whether you are a seasoned developer, a system administrator, or a software enthusiast, this documentation will guide you on your journey to harness the power of WASIX in your applications. As WASIX paves the way for the future of universal applications, let this documentation be your compass.

What is WASI?

WASI (WebAssembly System Interface) is a modular system interface for WebAssembly (Wasm) that enables developers to run Wasm programs on any platform, including the browser, the cloud, and the edge. WASI is designed to be secure, fast, and portable, allowing developers to write their programs once and run them anywhere. For more information on WASI, see the WASI documentation (opens in a new tab).

What is WASIX?

WASIX is the long term stabiliization and support of the existing WASI ABI plus additional non-invasive syscall extensions that complete the missing gaps sufficiently enough to enable real, practical and useful applications to be compiled now. It aims to speed up the ecosystem around the WASI so that the WASM’ification of code bases around the world can really start today.

In addition to toolchain support that we hope to upstream.

• rust compiler support (including an installable toolchain)
• rust tokio support (async runtime in the browser)
• rust mio support (abstraction of Wasm sockets)
• C compiler support (including an installable toolchain)

Extension for WASI

While WASI has been instrumental in advancing the Wasm community, its standardization process has been slow, lacking some crucial features necessary for traditional apps. WASI doesn't yet fully support threads, Berkeley sockets, forking, and other POSIX features that have been around for a long time.

WASIX comes into play to bridge these gaps. It extends WASI with most of the missing POSIX features and is designed to run both in the server and the browser. WASIX provides full support for efficient multithreading, sockets (socket, bind, connect), current directory support (chdir), setjmp / longjmp support via asyncify, pthreads support, process forking (fork and vfork), subprocess spawning and waiting (exec, wait), TTY support, asynchronous polling of sockets and files, pipe and event support (pipe, event), DNS resolution support (resolve), and more.

WASIX is also designed for high performance and is completely open-source. Its aim is to allow any existing program to run on WebAssembly workloads, speeding up the development process by not having to wait for the WASI committee's slower pace.

In a nutshell, WASIX enables functionalities in Wasm that are not currently possible with WASI alone.

What are the design decisions for WASIX?

• Backwards compatibility with WASI codebase - WASI code should compile against WASIX
• Forwards compatibility with WASI - WASIX will incorporate future additions of WASI)
• ABI additions are frozen when published, they will be served indefinitely by standalone or native runtimes.
• WASIX must provide the minimum capabilities to compile “useful” apps and components, in this case useful means (http servers, bash, curl, coreutils, nano , tokio , mio )
• There should be minimum code changes when compiling existing code bases (excluding standard library updates of course) - a code change needed in a code base is a flaw in WASIX.
• The ABI is to remain long term stable - no major refactoring is planned (including big refactors of WASI itself) - rather the plan is to stabilize the ABI for long-term and build out the support for existing code bases and standard libraries instead.
• When in doubt; copy POSIX syscalls.

How WASIX compares with Emscripten?

• Emscripten toolchain is complicated to iterate on, it requires a complex installation and dependency chain while also having non-standarized systemcall convention
• It is difficult to optimize Emscripten as the interface is bloated.
• Emscripten is mainly focused on running things on the web, while WASIX is specialized to run on both web and non-web environments uniformly. This also gives an advantage to Emscripten if you want to include the runtime with the codebase, as they will ship a more minimal package

How to use WASIX ?

Writing programs that use WASIX is very similar to writing normal programs in languages like Rust or C. The key difference is that you'll use the WASIX toolchain during compilation.

WASIX currently supports the following languages:

• Rust
• C
• Zig
• AssemblyScript (Support coming soon)

How to run WASIX programs ?

WASIX programs can be run on any WASI runtime that supports WASIX. Currently, the only runtime that supports WASIX is Wasmer. However, we expect more runtimes to join soon.

See the language guide (opens in a new tab) for more information on how to run programs with WASIX.

Can I contribute to WASIX ?

WASIX is fully Open Source and adheres to all licenses of the work it derives from and thus is open to contributions from anyone but must follow the key design requirements; especially the goal of long term support and stabilization. The intent is not to fork the WASI standard but to protect the progress already made so that engineers around the world can really get going with building great apps.

How to get involved with WASIX ?

• Join the WASIX Community (opens in a new tab) on Discord
• Join the GitHub Discussions (opens in a new tab) for official meetings