Starting external programs without using the EXE.xml

Is it possible (or could it be possible) to start external EXE’s when MSFS
starts without adding entries the to EXE.xml. XML files are very sensitive as
we all know. Any invalid character in them and they stop working. When you
have multiple developers all trying to edit the same EXE.xml, things often get
messed up. We experienced this in FSX and P3D regularly, and we are
experiencing it again in MSFS. Maybe I’m missing I’m missing something but it
would be so helpful if we start external EXE’s when MSFS starts without using
any XML files.

Am wondering if there’s update on this request, or maybe it was somehow
implemented and we missed it.

You might try a batchfile to start all the programs: START “MSFS” /D
“D:\Programs\Steam\steamapps\common\MicrosoftFlightSimulator”
“FlightSimulator.exe” -fastlaunch
START “LNM” /D “D:\Programs\Little
Navmap” “littlenavmap.exe”
START “TCalc” /D “C:\Users\dickl\Desktop”
“TCalc_004_feet.exe”
Save as MSFS_Start.bat and double-click it on the
desktop. Both TCalc and LNM use simconnect.

The goal is to have the program start when MSFS starts without requiring the
user to manually have to press anything.

Can any Asobo developer please comment on this. Without so many different
addons attempting to write to the EXE.xml, we’re finding several users now
have corrupted EXE.xmls, which can cause MSFS to crash, among other things.

Where is this EXE.xml? I can’t find it on my system at all… Best, Raul

There’s no plan to implement another way to start EXEs, and I don’t really see
how another implementation would solve the issue you are referring too: I
guess some 3rd party installer corrupts the XML when installing its add-on,
but it could happen the same way with .TXT or .JSON files. That being said we
should (and will) check why the sim crashes if EXE.xml is corrupted. Best
regards, Eric / Asobo

@EPellisier, @Boris Hi Eric, Boris, I can’t find any documentation about
exe.xml, can you give me some pointers about where I can find this file and
how to configure it?. Thanks in advance, Raul

<https://forums.flightsimulator.com/t/start-multiple-programs-on-msfs-startup-
with-this-exe-xml-tip/350698/18>

Thank you very much sir… Wondering why this is not in the SDK documentation
:slight_smile: S.

Hi Raul, If it’s not present, you need to create a file named exe.xml in

C:\Users\\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache

For steam version :

C:\Users\\AppData\Roaming\Microsoft Flight Simulator

Then you need to add this in it and modify the and the :

    SimConnect
    SimConnect.xml
    False
        
            Blender 
            False
            C:\Program Files\Blender Foundation\Blender 3.1\blender-launcher.exe 

In this example, when we start MSFS2020, it will start blender too after few
seconds :wink: Also, whenever you want to add an additional exe, you add a
section like the example above

Thanks you so much for the quick response Boris. All the best, Raul

One way to start an .EXE without having multiple installer risking corrupting
the one centralized EXE.XML might be starting an .EXE from a batch file
located in the MODULES folder ( or a new EXE folder ) of the Package itself.,
something like an AUTOEXEC.BAT of old, just that each package would have its
own. This way, every developer will be responsible from maintaining only his
own launcher, without risking breaking all other add-ons in the EXE.XML, just
because his installer has corrupted it. We are suggesting this, because in
years of FSX, the centralized EXE.XML “corrupted by others” was one the most
common single point of failure for add-ons that required an .EXE.

I would agree with that. I hope Asobo can accommodate it. The DLL.xml of
FSX/P3D, and now the EXE.xml of MSFS, is probably responsible for over half of
our support issues. We really need a simple way to start an EXE without
writing to a file (the EXE.xml) shared by multiple other parties.

HI Eric,

and I don’t really see how another implementation would solve the issue
you are referring too:
I guess some 3rd party installer corrupts the XML
when installing its add-on, but it could happen the same way with .TXT or
.JSON files.

Here is how another implementation has been solving this already. This is
quite simple and well documented: <https://www.prepar3d.com/SDKv5/sdk/add-
ons/add-on_packages.html>