deal with steam deployment isolation

[ab9rf]

We've been getting reports that the beta version of the Steam client is installing DFHack in a folder labeled "Dwarf Fortress 2346660" instead of in "Dwarf Fortress", which is breaking the way that we make our dfhooks library visible to Dwarf Fortress

After some discussion on discord the following approach seems to me to be the best method for dealing with this:

• Let Steam install DFHack wherever it likes
• The DFHack launcher will, each time it is launched, locate the DF installation and if necessarily push dfhooks.dll/dfhooks.ld.so into that folder, along with a dfhooks.ini that contains the path of the DFHack installation
• dfhooks will be modified to read this dfhooks.ini and use it to locate dfhack.dll/dfhack.ld.so and load it. This location will also be passed to the dfhack initialization and will be used as the dfhack app root folder location.
• If the launcher is being launched in "show-activity" mode (because the game was launched from DF, not from DFHack) it will check to see if an update to dfhooks.dll is needed and will schedule that update after DF exits (to avoid a locked file conflict) when needed

Backward compatibility:

• If dfhooks.ini is missing assume DFHack is installed in the same folder as DF
• If the parameter for passing the dfhack root folder to dfhack.dll is missing, assume DFHack is installed in the current working directory

[ab9rf]

Additionally, I think we probably should split dfhooks_dfhack.dll on Windows into a stub dfhooks_dfhack.dll that lives in the Dwarf Fortress directory, and a dfhack.dll that lives in the DFHack directory, with dfhooks_dfhack.dll having dfhack.dll as a required dependency. dfhooks_dfhack.dll would contain (basically) the contents of Hooks.dll and dfhack.dll would have (basically) everything else.

The reason for this is that we have to manually manage updating any components we inject into Dwarf Fortress's folder. Hooks.cpp changes very infrequently, and thus we can inject it once and only rarely have to update it; furthermore, it's likely that an update will be compatible enough with the immediately prior version that running once (or a few times) with the downlevel version will not result in misoperation. The rest of DFHack, however, changes with every update, and so we'd be reinjecting it each time it updates, and trying to keep each update downlevel compatible with the prior version is going to be much harder.

Something similar is likely required on Linux, but I don't know enough about how this is structured on Linux to know what needs to be done for that platform.

[ab9rf]

After further discussion, the solution that seems most straightforward and maintainable to me is to only inject dfhooks.dll/libdfhooks.so into the DF folder (using either installscript.vdf Run Process support on Windows, or via dflaunch on Linux), and then to modify our chainloader to, in addition to scanning the DF install folder for files matching the chainloader pattern (dfhooks_*.dll/libdfhooks_*.dll) also consult (on Windows) a specific registry key / (on Linux) a config file in a subfolder of XDG_CONFIG_HOME) to identify candidate chainloaded DLLs. dflaunch will be responsible for ensuring the appropriate settings are present, and will keep dfhooks.dll/libdfhooks.so updated as needed. This should also provide for backward compatibility and robustness during transition.