Because the game already also runs on Xbox and, given MS's recent gaming strategy (which is putting less emphasis on Xbox exclusives), could conceivably come to Playstation or maybe even Switch 2 in the future.

On the Windows side of things, there's also a push towards ARM hardware (with current Snapdragon-based hardware actually performing pretty well). Not sure if Flight Simulator is currently ARM-native, but having the ability to go ARM-native is probably desirable at least as a long-term goal.

Security is the big one. C++ DLLs have relatively free reign and are difficult to sandbox. With WASM you have a much stricter security model where the host program has full control over what APIs it has access to.

The addons are developed by third parties that aren't Microsoft, so there's a serious risk of malware and other ways of getting the user pwned.

The added future-proofing/portability is a nice bonus, but I suspect maybe not the main motivator.

Particularly for something designed to run on consoles sandboxing of addons is basically a requirement. Microsoft are never going to allow random people on the internet to run unsandboxed code on the Xbox because that's a fast route to people jailbreaking the DRM on them. I suspect the fact this also limits the use of Flight Sim mods as a vector for malware on Windows is just a happy side effect.

The real security for add ons would be to use external processes with OS IPC, even if it is more resource intensive.

But you'd also have to have an entire VM to run the separate process in, otherwise it still has access to the user's whole account and desktop.

(unless UWP I suppose, which even Microsoft have kind of forgotten about)

Sandboxing APIs exist for a reason.

Which APIs guarantee non-escape of native code?

WASM brings a memory sandbox that prevents out of bounds access to arbitrary pointers.

The only bounds that are checked is the overall size of the linear memory block, there is no bounds checking inside the same segment.

Right. The sandbox can scramble its own state, but as long as the accessible APIs have a protected interface it can't mess up the overall game.

Which is exactly the point made by GP.

There were already parts in MSFS 2020, namely gauges aka everything in cockpit that had more dynamic display, that used JS based SDK in order to provide sandboxing and safe level of control over performance (because with sandboxes VM it's easier to preempt execution)

Also it allows playing Flight Simulator inside Flight Simulator :-)

https://github.com/s-macke/FSHistory/tree/master?tab=readme-...

Does this still work?

Potentially related: a detailed write-up on creating a JavaScript autopilot/interactive webpage

https://news.ycombinator.com/item?id=40267164

Does this still work?

gauges in JS? that's how all gauges with dynamic display works in MSFS 2020 and presumably 2024, so yes it still works.

Oops, I meant to reply to the "flight simulator inside flight simulator" easter egg message

WASM provides a secure sandbox with predictable performance across platforms while giving Microsoft the ability to maintain compatibility if they port to Xbox, cloud, or other platforms without requiring developers to recompile their add-ons.

Isn’t there ARM windows too? Not sure if flight sim targets that platform or not, but if so, making the extensions more portable is a win.

> Is it for future proofing it in case MS wants to release the game in a different platform that is not windows ?

Strongly rumored to be releasing on PS5, like most recent Microsoft games.

It runs on Xbox as well so I imagine they want the flexibility there.