Looping

Normally, graphical C++ applications run in an infinite loop. They react to events and process them with each loop iteration. At the same time, rendering occurs, and a wait is built in to keep the frame rate (frames per second, or fps) constant.

This behavior is less suitable for browsers, because the continuous loop makes it impossible to return control to the browser. The Emscripten SDK therefore provides a function for C++ code to prepare the main() loop for use in JavaScript. This function guarantees that the website is not caught in an infinite loop. The Emscripten API reference [18] reveals more, especially the passage on the emscripten_set_main_loop() function.

Matching Filesystems

Native programming languages often use direct, synchronous access to the filesystem. Browsers, however, do not access the filesystem directly, and JavaScript usually runs file operations asynchronously. Emscripten provides a virtual filesystem that allows the browser to run native applications without major changes. Applications that use synchronous file access, access the virtual filesystem via an API (Figure 4).

Figure 4: Emscripten provides filesystems in RAM that are suitable for synchronous access (from Emscripten GitHub docs [19]).

By default, Emscripten relies on MemFs [20], a filesystem that resides in memory, that Emscripten automatically mounts on the root directory (/) when necessary (when the code requests file operations). MemFs users use emcc to add files and directories to the filesystem that are then available later when the program runs in the browser.

A website with access to MemFs loads the files via JavaScript; it does not allow synchronous file access until the entire filesystem is available in memory. Because MemFs only exists in memory, writes are lost on refreshing the website page.

Listing 2 shows a simple C program that reads a passwd file from the current directory and outputs the first entry of each line. MemFs needs to provide the necessary text file at build time; emcc provides two options, preload-file and embed-file.

Whereas preload-file instructs JavaScript to load the transferred files when calling the website, embed-file integrates the files directly into the JavaScript file produced. If the developer now uses

emcc vfs.c -s WASM=1 -o vfs.html --preload-file passwd

to call emcc, the compiler generates a file named vfs.data, in addition to the WASM, JavaScript, and HTML files containing the transferred file. The program then accesses these at run time.

To save data, Emscripten provides two MemFs alternatives, depending on the application: node-fs [21] and IDBFS [22]. The node-fs library is only used if the application runs within a Node.js environment. Thanks to node-fs, applications access the entire local filesystem via the Node.js API. If you need the browser application to write persistent files, IDBFS provides a synchronized IndexedDB instance.

Additional restrictions for portability are described in the Emscripten docs [23]; they mainly relate to multithreading applications and programs that involve low-level hardware features and native assembler instructions.

Chain of Tools

Emscripten provides a generic toolchain that also creates asm.js code, and WebAssembly has its own tools for reading and editing WASM files directly. The two sets of tools are the WebAssembly Binary Toolkit (WABT, "wabbit") [24] and Binaryen [25].

WABT provides tools that help translate between the WebAssembly's binary and text formats, an objdump version for WASM files, and a WASM interpreter. In contrast, Binaryen primarily offers a library to facilitate the compilation of code in the WebAssembly format within other toolchains. It also provides some additional tools to convert between the WebAssembly binary and text formats and between asm.js and WASM, as well as a WASM interpreter. Last but not least, Binaryen has a JavaScript library of tools.