Ok, I’ll go in chronological (historical) order:
The Gauges API
This is the oldest API, which came with FS2002, it’s a set of C/C++ functions calls, which were initially the only documented API in the sim, was used mainly ( but not only ) airplane developers writing C/C++ gauges, and contains many functions to read simVars ( A: variables ) and “XML” vars ( L: variable ), it also contained the “universal” execute_calculator_code, which evaluated an XML expression written using the XML Gauges syntax, which could also be used to read/write variables and/or send events to the sim, like keypresses. This could also be used by developers writing stand-alone .DLL modules that ran in-process to the sim.
The SimConnect API
This is a later API that came with FSX, it’s client-server based so it can be used for both in-process .DLL modules or gauges, but also for external .EXE, not necessarily running on the same PC, because it can also networked. It’s also supported in P3D, and it’s far more powerful there. It supports .NET and managed code, while the Gauges API it’s C/C++ only.
Since it has been around for a very long time, it’s well documented and still developed (not just by Microsoft, since P3D use it too), it’s by far the most used API. However, it lacks access to things only possible ( L: vars and XML expressions ) with the Gauges API.
WASM
This is the new way to create C/C++ code for MSFS. While Simconnect is still supported, it’s only for external .EXE. C/C++ Gauges and Stand-Alone modules (modules that starts with the sim and ends when the sim exits), that is everything that run “in-process”, MUST use WASM. However, WASM Gauges/Modules CAN make Simconnect calls as well. The main difference compared to the old FS8/9/FSX Gauges/Modules, is they are heavily sandboxed, meaning they don’t really have access to the simulator address space and can’t even read any files outside their own package. They can write only on their dedicated area. The main advantage of WASM, is that you can still use C/C++, it’s almost as fast as the true native code, and it’s cross-compatible with Xbox. Also, with WASM ( this is the important bit ), you ALSO have access to the “old” Gauges API, the one I listed first.
By putting together all of this, someone needing to access variables and events not accessible directly through Simconnect, has to do the following:
-
Write a Stand-Alone WASM module ( but also a WASM Gauge would work ) that would use the Gauges API to read variables or receive/send events which wouldn’t otherwise possible to get through Simconnect.
-
Use the Simconnect API in the WASM module to define custom data areas which can be used to “send outside” these results, to a external Simconnect client that would connect to the WASM module. This is bi-directional too, the external client might ask the WASM module to perform commands/events on its behalf, not just read data from it.
Now, why all these complications ? Wouldn’t be easier/better doing everything through WASM ?
No, you can’t, because WASM is heavily sandboxed: in addition to not being able to read any files outside its own package, it doesn’t even have ANY access to ANY of the Windows APIs ( no Win32, no .NET, nothing, just basic Posix and only in your own folders ) so, even if WASM has a somewhat privileged access to the sim compared to just using Simconnect, it can’t do much with it so, you’ll realize soon enough you need a “real” Windows .EXE for almost everything, especially if you need to interface with some hardware.
That’s why the need for bi-directional communication between WASM and another .EXE, using Simconnect “as a transport”.
It’s really outside the scope of this post explaining in detail how the Simconnect client data areas and custom events work but, if your goal is JUST interfacing with some hardware, it’s likely easier if you use the Mobiflight module, which has all the basics done and has some specific functions for the A320-NX