I am not sure I am following. The game runs on windows, why not compile the add-in code directly for the single target?

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

JonathonW 5 days ago | parent | next [-]

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.

▲

potatolicious 5 days ago | parent | prev | next [-]

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.

▲

jon-wood 4 days ago | parent | next [-]

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.

▲

pjmlp 4 days ago | parent | prev [-]

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

▲

pjc50 4 days ago | parent [-]

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)

▲

pjmlp 4 days ago | parent [-]

Sandboxing APIs exist for a reason.

	▲	pjc50 4 days ago \| parent [-]
		Which APIs guarantee non-escape of native code?

▲

connicpu 5 days ago | parent | prev | next [-]

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

▲

pjmlp 4 days ago | parent [-]

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

	▲	connicpu 4 days ago \| parent \| next [-]
		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.
	▲	senorrib 4 days ago \| parent \| prev [-]
		Which is exactly the point made by GP.

▲

ethan_smith 4 days ago | parent | prev | next [-]

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.

▲

p_l 5 days ago | parent | prev | next [-]

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)

▲

dividuum 5 days ago | parent | next [-]

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

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

	▲	anonymars 4 days ago \| parent [-]
		Does this still work?

▲

anonymars 5 days ago | parent | prev | next [-]

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

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

▲

anonymars 5 days ago | parent | prev [-]

Does this still work?

▲

p_l 4 days ago | parent [-]

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

	▲	anonymars 4 days ago \| parent [-]
		Oops, I meant to reply to the "flight simulator inside flight simulator" easter egg message

▲

hamburglar 5 days ago | parent | prev | next [-]

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.

▲

tapoxi 5 days ago | parent | prev | next [-]

> 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.

▲

01HNNWZ0MV43FF 5 days ago | parent | prev | next [-]

In addition to the sibling comments, you can sandbox WASM's CPU time. You can say after a certain amount of time that it has to yield back to the host. With native plugins, you might never get your OS thread back, and there isn't a good way to safely abort it and free memory and everything

▲

selectodude 5 days ago | parent | prev [-]

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