Run Wasm Outside the Browser Using WASI

WASI: Wasm Outside the Browser

WASI (WebAssembly System Interface) gives Wasm modules portable syscalls: files, clocks, randomness, without baking in a JavaScript host. Runtimes like Wasmtime and Wasmer implement WASI on Linux, macOS, and Windows.

Capability-Based I/O

Instead of implicit full filesystem access, WASI uses capability handles passed at instantiation:

• \`fd_write\` to stdout via preopened descriptor 1
• \`fd_read\` for input
• \`clock_time_get\` for monotonic time

Compile with \`clang --target=wasm32-wasi\`, link with \`wasm-ld\`, run with \`wasmtime run hello.wasm\`.

For example, \`printf("hello\\n")\` lowers to WASI \`fd_write\` on the stdout capability the runtime injects at startup.

This is how Figma-scale C/C++ codebases run server-side without a browser embedding.

Design Notes

Preopened directories are capabilities, not global filesystem access. A module cannot open `/etc/passwd` unless the runtime explicitly grants that path at instantiation time.

For This Exercise

This exercise asks you to document running a Wasm module under WASI. You will explain the compile flags, runtime command, and how capabilities replace browser JS imports for I/O.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.