DLL vs. WASM modules

[MSFS 2024] Questions & Community Discussions SimConnect
1

I am developing some general modules (not instrumentation/gauges) using SimConnect. So far, I developed them in C++ and compiled to WASM, but as I expand functionality, I am increasingly hitting some WASM coding limitations. So, I’d like to switch to DLL, however, I am not sure if DLLs can be included in the packages the same way as WASM modules. Can anyone confirm this? Can DLLs be included in packages that are marketed on MSFS Marketplace? Will they be XBox compatible? (I am guessing not). Can anyone share some guidelines or share some light on this?

Any input would be appreciated.

2

There is no system for loading DLLs, but you can make a standalone executable. In that case, you can’t distribute on marketplace.

Could you elaborate on the “WASM coding limitations” you’re hitting? In 2024 the major limitation is you have no multithreading, but you do have like almost a whole thread that can really do a lot computation every frame.

3

Lack of multithreading might be nice, but it’s hardly the major limitation in WASM. The biggest showstoppers are:

  • No access to the Windows API (or any other API), because there’s no way to link to any library, either statically or dynamically. The only possible way to extend your code with add-on libraries would be using those that comes with just self-contained C++ code, like boost, which you can’t use because of the following:

  • No support for C++ exception handling, which makes porting exiting C++ code hard, especially if you want to use frameworks like boost

  • No support accessing files outside your package, not even in read-only mode. An example why this might be required, is that Simconnect doesn’t provide with an 1:1 representation of each and every parameter defined in the various aircraft .cfg files, but only a subset (you can’t read things like the airplane icao_airline or the icao_type_designator, but not only), so you would need to access the .cfg file directly, which you can do it with external executables of course, but not from WASM, which is sandboxed to your own package only to read, and your own working folder in LocalState to write.

As an example, the new very interesting feature to have airports with their own custom WASM modules, loses a lot of possible usage cases without access to missing SimVars. The previous example of missing an icao_type_designator SimVar, would force detecting the airplane type using unreliable heuristic from the ATC MODEL or TITLE SimVars, missing the point of having an icao_type_designator, which seemed to have been designed precisely to uniquely and reliably identify an airplane type, which might be used, for example, on an airport-specific VGDS system.

Lack of (read-only) file access to the whole VFS might not be so much of a problem, if Simconnect was extended by adding SimVar for all possible airplane parameters but as long it isn’t, there’s just things you can’t do with WASM right now.

The key issue is, if Microsoft wants more developers that up to today where forced to use standard .EXE/.DLL so they could code everything without any limitation, and be able to sell lots of interesting add-on that are currently outside the Marketplace, a good way to push usage of WASM, would be Improving Simconnect, because every new thing that goes there will help WASM adoption.

1 Like
4

Hi everyone,

Just to comment on a few ideas discussed here:

  • Multithreading: we are still willing to implement this at some point but up to now this has proven very difficult to do because of many technical hurdles - sure we could overcome them by putting a dedicated team on the topic for weeks or months, but we cannot really afford to do it right now (too many other things on our plate). That being said - as you know WASM modules now run on threads which should already be better than the MSFS 2020 situation.
  • C++ exceptions: although WASM opcodes to mimic try/catch C++ mechanisms have been available for quite some time, the wasi-libc we provide in our toolset did not allow to use them last time we upgraded it. It looks like recent changes (April 2nd) may solve the issue, so we will have another look at upgrading after the launch of MSFS 2024 - it will probably require changes on our end too.
  • File access: there isn’t and I think there will never be “full access” to the player’s hard drive for obvious security reasons - this is not to say we will never have some kind of “shared” storage space between WASM modules, but we need sample cases to assess proper design for this.
  • Just for the record: SimVars are not a “SimConnect only” topic - if we publish more SimVars they’ll be available from JS/WASM without the need for SimConnect.
  • With the above in mind, I am not convinced creating even more SimVars is the best way to have more people working with WASM. Having dedicated APIs for specific aspects (Aircraft, Airport…) would seem more logical (and efficient performance-wise) to me.

Happy to discuss these topics further in the coming days/weeks! :slight_smile:

Best regards,

Eric / Asobo

5

You mention boost as a specific example; older versions of boost work out of the box e.g. 1.66 doesn’t use exceptions or threading.

6

Boost 1.66 is from 2017: if having to use a 7-years old version of a library is not a limitation, I don’t know what else is. Clearly, anybody having to port recent code using a non-ancient version of boost so he used exceptions, would either have a very hard time refactoring that code, or he will just give up.

And yes, exceptions might also happen in a pure sandboxed environment, not just in file or network operations that might not be possible under MSFS WASM anyway. Take error handling across different languages, like in Boost::Python, where c++ can handle a Python error (which can be anything, not just file/network issues) as a c++ exception. That’s just one example.

1 Like
7

@EPellissier ,

thanks a lot for your reply. I’m happy to hear you are considering adding exception handling to MSFS WASM, it would be a great step to make it more useful (and to reuse existing code).

About file access: I would never expect we’d be given access to the whole user hard drive. If that is really needed, I’m sure the app will just have to accept being released as a separate .exe and will never hit the Marketplace.

However, I referred to “(read-only) file access to the whole VFS”. Considering the MSFS filesystem is already virtualized, you might be able to supply with MSFS-specific file access APIs that would limit access to the MSFS filesystem only.

About SimVars, I assumed it would be easier to just add SimVars than a whole API but, what really matters is the end result, not the way it’s done.

Sure, having an Aircraft access API that (similarly to the Navdata API) would grant access to all possible airplane settings and values, included the ones not available as SimVars, that would be very useful and probably even better than having to access file outside the add-on own’s package folder.

In any case, if you wanted an example of an usage case of why file access (virtualized!!!) to other package might be useful, consider this:

An add-on with an option to support its own “add-ons”, which could be released as separate packages, but since they use constructs that are very specific to that add-on and don’t fall into any of the existing MSFS systems, they must be recognized as such by the main product, which will need to read custom data files from their packages. Nothing particularly strange or exotic: it might just be custom sections in a SIM.CFG file that are not used by MSFS, for example, but they are by the main add-on, which will have to parse those to enable its specific behaviors.

This is fairly easy to do by having access to other packages, but impossible under the current sandboxed WASM system, and would be feasible if we could at least get access to the virtualized filesystem.

8

I agree with you, was not saying no exceptions is not a limitation, was just pointing out that boost can work.

9

Thanks everyone on chiming in, I am really glad my question started up this conversation, it has been really helpful. @StevenPearce833 to elaborate, pretty much everything that has been mentioned here is throwing me hurdles. I am working on a module with functionality that would be useful to other aircraft devs (an add-on to an add-on, as someone here remarked). The functionality would be specified in simple text CFG files, however, there is no way of me getting to other aircraft’s CFGs. Now I have to ask them to drop them into my module’s directory during installation, or even manually, so I am not sure how to handle this. Moving down the list, not being able to link to libs (I needed a simple XML read/parse/write utility and had to write my own), through exceptions, multithreading, etc.

I’ve been developing for P3D and the DLL scheme was very flexible. I understand the need for WASM, but I wish the DLL option was kept (as was EXE), with the possibility of including it through Marketplace and option not to include XBox support.

10

IMHO anything loaded as a “plugin” should need explicit permission to do anything outside a sandbox. Like in a browser (but better).

That includes scanning thousands of files in the game folder or whatever crazy idea someone comes up with next (not saying that’s what you were planing @HornetJockey685 , but your comment reminded me of someone who did want to do that).

While I’ve been frustrated by the limitations as a developer, I appreciate them as a user.

External deps have to be added as source code or static and compiled in. I added logging and INI file parsing this way (the logger did need a few small tweaks to run w/out std::threading but wasn’t a big deal). Choose the simplest libs with no deps. It’s more work, sure, but the WASM code is essentially running inside a web browser environment so compromises need to be made. :person_shrugging:

Cheers,
-Max

1 Like