Hi.
I don't know much about hardware, and my flightsim background goes only up to FSX (FS9, FS2002... FS4).
But I think there are only three ways to communicate with FS :
1) The most used is called a module. Basically, it's a third party DLL (and eventually an indefinite number of dependency files, text, binary, other dlls, even .exe, etc. all setup in specific directories by design). The DLL is installed in the modules directory of the sim, it's a software piece of code that become a runtime loaded assembly or resource of the sim (don't mind my choice of words, focus on the meaning). It gets loaded by the sim only if it implements the SimConnect concept/scheme explained in the SDK. Most people (developpers) out there goes with this way, much simplier and opens a variety of capabilities offered by design by the sim (read/write variables, commands, visuals, sounds, etc.) Examples are FSUIPC, WideFS, many aircraft and scenery addons that goes deep in communicating with the internals of the sim (the like of PMDG...)
2) Create a peripheral, basically, something emulating a keyboard, mouse, joystick, etc. That hardware would be properly installed on the system with the appropriate driver (that you would auto install via a plug-n-play scheme - that's the expected behavior). The peripheral (controller) would be listed in the system as any other, and, once in the simulator, one has just to select and configure it. However, that's NOT really a two-way communication, as the inputs (control -> sim) is the expected kind of possible actions, and the only output (sim -> control) would be force feedback (or whatever it is called today, like a joystick shaking when the aircraft stalls). There are specific patterns to learn to implement such game hardware features, I don't know much about them, and I believe you want much more than just controls reacting to feedback (in that case, you would go 1) in the first place).
3) A software with exceptional privileges, on an admin computer/session, that bypasses all the windows memory protection, that directly read/write into flightsim. That's overly optimistic, and would only apply to those like me who are a decade or two late, with Windows 7/Windows XP (where you could do a bunch of crazy things with C).
You talked about some .ini files. I don't own any RealSimGear, too poor for that, but on their site, they explain they have two types (probably more) of ini files :
- the system config, located along with the RealSim module in flightsim (or the linked directory path on later sims), it acts mainly as a dictionary that stores upon first activation wich COM port (USB used as COM) the hardware is plugged on.
- the commands mappings, as a general one, and some custom ones you can put in any aircraft directory.
^^ the later rings a bell in relation with your question : if you assumed that was some kind of USB configuration that magically binds the RealSimGear buttons/knobs and screen touch to the simulator, you're probably mistaken. RealSimGear appears to also go the 1) option above mainly, most likely associated with option 2). It's the RealSimGear module (a DLL loaded by the sim) that would read the ini files, not FS, not windows. It would then intercept the inputs from the hardware (would be listed as a peripheral on the system), remap the commands in memory, and send the appropriate-FS-compatible command via the SimConnect scheme. The same the other way around.
I also read the their hardware are on the visual-side extra screens, basically, with control hardware around.
I don't know for sure, but my understanding of hardware "two-way connected" with the sim requires one or several modules, a DLL, a piece of software code one must write, compile and install in FS, to translate whatever computing command/data-transfer (software/hardware) into and back from FS-understandable commands/data transfer. There is no basic simple ini file config, or that would be :
- either implemented by design, explained in the SDK, and probably very limited (like cfg files, you write text, and voila, it works, but, that's about what it can do)
- or implemented by design, not explained in the SDK, and only a few would know about, because that would be so prone to security and exception issues, it would be bad to let anyone play with it.
As an alternal example, one could use cheap hardware components to create an on/off button or lever, let's say, a landing gear lever, then use Arduino to code drivers and connect the thing to the PC via USB. The way to communicate with FS is also a module, that would identify the hardware, it does not have to be on a COM emulated port. It does not even have to be an hardware, you can use a module to communicate between your own made software and the sim, directly, or put your software on a remote computer, or over the internet, and make a module that handles the network communication. You can make a module that send FS data stream over some cloud, create another software for a tablet that downloads streamed data from the cloud and shows the datas, then input commands on the tablet screen that are send to some cloud, and make your module stream download from that cloud to command FS....................... That's the scheme. The SDK only explains SimConnect, you have to write your software/hardware handling logic yourself.