@ExactableFiend8
I believe you’re raising valid questions but the truth of the matter is that it is unrelated. If you’re not a developer, I fear you might feel what I just wrote is condescending, but it is not, and I’ll try to explain.
To get started, all simulators in existence, and many games, are allowing modding via DLLs running in the same process space. This was never a security concern and in practice, in the Flight Simulation world specifically, this has never been a security problem at all. 3rd party vendors, both professionals for which this is their sole job and revenue like Reality XP, or for which this is a part-time job, and freeware authors alike, are all making their best to delivering bug free and safe add-ons for their users.
But even if there is a rogue vendor wanting to exploit either or both Azure and Xbox Live, I can assure you there are already ways to load DLLs to do just this in FS2020. I’m not talking about system wide DLLs injection/loader here, I’m talking about a security loophole in the FS2020 implementation they can’t patch, that I didn’t publicly documented yet, and is unrelated to WASM or loading 3rd party add-ons. And even if you’d load a DLL in the FS2020 address space, it wouldn’t give you any better way to exploit Azure and Xbox Live in much meaningful ways anyhow.
Like I said above, I agree, WASM is a good technology for the 1st of their goal: ensuring you only have safe code in the market place. WASM might be a good way to run generic C++ code over a wide variety of devices, no doubt about this, but sandboxing is not a good technology to port legacy add-ons in C++ in particular, because most sophisticated gauges are working outside the box, not inside. In addition the current sandboxing implementation doesn’t allow interfacing with external applications in a way we can ensure both throughput and latency.
This is very easy to solve though. You can ensure both sandboxing protection from rogue code, and ensure low latency with 3rd party code, in adding support of IPC in the SDK for the PC version only. With this, any 3rd party gauge could be split in 2 parts: the sandboxed WASM part in-process, and a separate standalone executable running in its own separated process space. The IPC would be used to make the 2 sides communicating the data they need back and forth.
If you look at this, it is no different in principles that what the JS/HTML layers is forcing the developers to do already: in order to make an add-on displaying something external, you have to build and run a local webserver on your computer listening to requests coming from the simulator and sending back HTTP responses to the JS code running in the “gauge”. Now imagine in a few years, you’ll be running maybe a dozen or so local web servers just to feed your add-ons in FS2020. It is really not lightweight an implementation.
With IPC, you’d open the capability for WASM gauge to do the very same, but in a C++ efficient and close to the metal way (no web servers, no encapsulation of data in JSON response text and HTTP requests, no more RAM allocated to wrap a 2 byte answer into a 1500 byte frame, etc…). With IPC, each developer will build its own protocol to exchange data between the WASM gauge side and the external code side, in the most efficient way for this gauge. But more importantly, with some latency and throughput garanties.
Adding such IPC capability in the WASM SDK is not opening any security hole at all either. And if this is really a concern, they could restrict the IPC API to being available to sandboxed WASM code running on the PC version only (not the Xbox version).
Sandboxing is good to port existing C++ gauges ini theory, but not in practice. If this was so good a way to do so, we’d already have much more aircraft ported over from renown vendors already. The reality is that 3rd party vendors have been able to delivering sophisticated add-ons for their customers enjoyment mostly because they’re implemented outside the box. I’ll try to illustrate this:
From FS2020 point of view:
- FS2020 is commanding the gauge, sending events when it must init, update and draw.
- Gauge gets some API to read some simulator data, code can process the data, code can draw the data.
From 3rd party point of view (before FS2020):
- SDK has a few bindings to sync init, update, draw gauges
- SDK is offering static constructs to define the gauge elements like needles, background gauge bitmap, which must be set statically during compilation.
- SDK is offering pre-defined rendering of these elements, gauge can influence some of the parameters.
- SDK is offering API to read some simulator data.
- Gauge use all available resources in the computer to process the data the most efficiently possible
- Gauge connects to internet, read files, use compute shaders on the GPU if needed.
From RXP gauges point of view (and actual implementation):
- FS has a certain set of entry points and sync points.
- SDK is offering some static constructs meant to “simplify” building gauges but these are based on dynamic constructs underneath.
- Gauge is using the SDK in a way to bend the simulator through the SDK to the gauge needs.
Here is some more details about the RXP gauges:
-
FS is instantiating gauges based on the statically set elements during compilation. This is a layer built on top a lower level older SDK which has direct entry points to servicing the different phases of construction, handling and destruction of gauge instances. Knowing how this works allows RXP to delivering gauges using this static compile time constructs but to create gauge at runtime entirely, not statically compiled, and to adapt the gauge depending on the user preferences. This includes the gauge elements, the mouse click spots, the rendering.
-
SDK is limiting rendering to pre-defined handling of elements with 1 bit of transparency and 15 bits colors. Underneath, the rendering is capable of handling 32 bits colors and alpha transparency, but the SDK is not clearly exposing this. RXP gauges are not relying on pre-defined elements, instead, they are rendering any surface in 32 bits with alpha, but always using the underlying simulator gauge rendering code which makes the gauges capable of doing this from FS9 to P3D5 as-is.
-
SDK is offering API to read some simulator data but is lacking any overriding capability to this data (unlike XP11). Because 3rd party GPS gauges need to “replace” the stock GPS which is hard coded in many places inside the FS code, especially directly hard-coded in the autopilot code for example (to the point the FS code is forcefully setting vertical deviation to 0 because the stock GPS doesn’t offer any form of vertical navigation, although the code is capable of supporting such GPS input if it wouldn’t be forcefully set to 0 in the autopilot code…). The RXP gauge is patching the FS code at runtime to augment its capabilities with autopilot flight director override, and simvar override (both XML and C simvars) so that any other 3rd party aircraft gauge reading the SDK var will get its data from the RXP GPS instead.
-
SDK is lacking any introspection API, which is preventing a gauge to knowing which panel.cfg file it is instantiated from. This is not important to know if you’re an aircraft vendors because all the gauges are yours. But this is important to know for customers wanting to merge and mix gauges from different vendors in a generic way. The information is already there in the SDK structures, but it is not exposed publicly. RXP gauge is exploiting this information in order to make generic gauges fitting any other 3rd party aircraft.
I could tell more about all this, but it might be already boring enough 
Suffice to say, I’ve a certain perspective and expertise on the SDK for 3rd party gauge development which is due to the specific needs to implementing gauge/gauge and gauge/simulator integration beyond what an aircraft vendor is dealing with. In successfully delivering solutions to these challenges, I’ve also been able to confront the SDK strengths but also its shortcomings and what it is entirely lacking but essential. This is further confronted to the fact the RXP products are not using any hack whatsoever on X-Plane but couldn’t be built without hacks on any Flight Simulator version, which in itself, is revealing that different and better suited SDK approaches are available to address some of the challenges 3rd party gauge developers are facing.
This is just a glimpse of my 20 years old expertise building retail and professional flight simulation add-ons. Although the above is talking about the past, please don’t see this as a way for me saying FS2020 should revert to antiquated SDK constructs and methods, this is not the point at all.
On the contrary, FS2020 has the unique chance to depart from ancient constructs and old habits, but unfortunately, the SDK is still lacking at the very same fundamental architectural principles, and this is what I’m trying to help with.
