Microsoft Flight Simulator 2024: WebAssembly SDK

Original Article ↗ Hacker News Discussion ↗

WASM as a Plugin / Module Platform

  • Many see WebAssembly as a natural fit for modular, pluggable systems: compile C/C++/Rust/Go to WASM, define gRPC/proto-like contracts, and swap components freely.
  • It’s viewed as a potential “run-anywhere” layer, but others note this is limited: WebAssembly itself has no system interface, and WASI currently exposes only a tiny fraction of what JVM/.NET standard libraries offer.
  • For plugins specifically, WASM’s lack of ambient system access is seen as a strong positive: the host defines a tightly-scoped API rather than exposing OS primitives.

Why Flight Simulator is Using WASM

  • Main motivations discussed:
    • Security sandbox for third‑party add-ons, avoiding native DLLs with free access to the user’s account and filesystem.
    • Cross‑platform / future‑proofing (Windows + Xbox today, possible ARM Windows or other consoles tomorrow).
    • Better control over CPU time and the ability to preempt misbehaving modules.
  • The SDK essentially treats WASM as an intermediate language that’s JIT‑compiled to DLLs at startup, aiming to keep performance close to native.

Security Model vs OS Responsibility

  • One camp argues this is compensating for OS failures: the OS should sandbox apps and prompt for permissions; if that existed, DLLs would be fine.
  • Others reply that given current OSes and GPU licensing (notably limited consumer vGPU), an app‑level WASM sandbox is a pragmatic solution.
  • There’s disagreement over how pervasive malicious mods really are: some cite concrete incidents (e.g., Minecraft), others call the risk overstated.

Quality, Crashes, and SDK Rough Edges

  • Several players report MSFS 2024 as crash‑prone and performance‑regressed vs 2020, especially in VR or 4K due to VRAM limits and DLSS tradeoffs.
  • “WASM crash?” has become a common meme in streams; typically the sim survives but critical WASM aircraft systems die, effectively ruining the flight.
  • Some note that WASM overhead can be quite low (<~10% vs native in their experience), with sandboxing mainly adding a memory mask per access.
  • The SDK’s “Known Issues and Limitations” (no WinAPI, C++ exceptions/threads, partial GDI+ wrapper) are seen as realistic for a sandbox but discouraging.
  • Error handling is criticized as inconsistent across APIs; calls for a more unified errno‑style approach.

Modding Philosophy and Alternatives

  • There’s tension between strong sandboxing and the “old days” of open DLL source modding; some fear over‑securing will stifle creativity more than it prevents rare malware.
  • Others argue a standardized, sandboxed API improves interoperability and is mandatory for consoles.
  • Alternatives like Lua (source or bytecode) are proposed for simplicity; pushback centers on performance for high‑fidelity flight systems, where C++→WASM is favored.