Way for user to provide external DLL paths (e.g. mfplat and friends) to Proton

[mbenkmann]

Feature Request

I confirm:

• that I haven't found another request for this feature.
• that I have checked whether there are updates for my system available that
  contain this feature already.

Description

Many games run at all or with more features if they have access to the official DLLs from MS. The Media Foundation DLLs are the most common offender. At the same time many users have easy access to these official DLLs, e.g. from a preinstalled Windows partition on their computer. What is missing is an easy way to allow the user to inject these DLLs into Proton on a general and a per-game basis.

I suggest the following:

1. Proton should read a simple text file from a defined location within the user's realm of control, e.g.
   $HOME/.config/proton/extra-dlls.ini

2. The file should contain a list of paths of directories where the user has official Windows DLLs available (e.g. a mounted Windows partition)

3. The file should contain a list of DLL names and identifying hashes (e.g. md5) found in those directories. This list should be in a format easy to generate for the user, e.g. the output from md5sum *.dll within a directory.

4. The file should have sections for 32bit and 64bit with each section containing a list of preferred hashes for each DLL, e.g.

       [32bit]
       mfplat=40b82688907a7dba4db3b5adde3eab3b
       [64bit]
       mfplat=54b5dcd55b223bc5df50b82e1e9e86b1
   

5. The file should have sections for individual games (identified by some ID, e.g. Steam's name) with a list of preferred hashes. E.g.

       [Spyro Reignited Trilogy]
       mfplat=54b5dcd55b223bc5df50b82e1e9e86b1
   

6. When Proton launches a game, it checks if the above file has a section matching that game. If it does, Proton reads the list of DLL names and their preferred hashes from that game's section. Proton combines this user-provided info with an internal list shipped with Proton. If no section for the game exists in the text file, Proton only uses its shipped info (if any). Proton adds in the information from the general 32bit or 64bit section depending on what is appropriate for the game. The result is a list of DLL names and hashes that would be desirable to use with the game.

7. Proton uses the hash list described in 3. to quickly check if all of the desirable DLLs are made available by the user. This is preferable to scanning the list of directories because that may be very slow AND the user may not actually want to make available all DLLs he has lying around to Proton.

8. If and only if all of the desirable DLLs are available based on the check 7. does Proton scan the provided directories from 2. to locate an actual instance for each DLL with the respective hash.

9. Only if all desirable DLLs are found in the proper version as defined by the hash, does Proton replace all of its internal Wine-provided counterparts of these DLLs with the external versions and adds all of the external DLLs for which Wine has no counterpart to its runtime environment for the launched game instance only. This means no piecemeal adding of incomplete sets of DLLs and no permanent modifications to the whole Proton instance that could influence other games. The external DLLs used for this launch should probably be copied to a temporary location used only for this specific launch. No matter the implementation, it must be ensured that if the user removes or changes the info for the game in the text file, the new info takes effect for the next launch of the game with no leftover DLLs from previous launches being injected. It must also be ensured that other games launched with the same Proton instance do not accidentally use DLLs not configured for that game.

Justification [optional]

Wine has mechanisms for using externally provided DLLs with a Wine installation, but these are unfit for Proton for the following reasons:

1. Steam installs Proton in the background with no user intervention. There is no easy way for the user to access Proton's Wine installation.
2. It is not desirable for the end user to touch files within Proton's installation by direct Wine-provided means, because that could break things in weird ways.
3. Proton is often updated via Steam and multiple versions exist in parallel. A mechanism is required that allows the user to maintain the list of external DLLs (and the DLLs themselves) he possesses independently of all these installations, so that they carry over with each update and are available to each installed instance of Proton.
4. Different games have different requirements. Even with the same Proton version you may want to use different sets of external DLLs for different games. Wine does not have or want a mechanism to provide different sets of DLLs for different apps run with the same Wine instance.
5. A simple text file as described above allows for easy sharing of snippets via games forums like Reddit that even unsophisticated users can copy'n'paste into a text file. If something breaks it is easy to revert for the user.
6. Unlike Wine, Proton is targetted specifically at a known and limited list of game programs in specific versions sold on Steam and Proton can ship curated black and whitelists of DLLs that help or hurt specific titles. This allows for the combination of knowledge from the user (which DLLs does he have and where on the disk) with knowledge from the Proton developers (which DLLs would be useful for a specific title) to create an out of the box experience where a game just runs.
7. Not having this feature implemented in Proton leads to people forking Proton (e.g. GloriousEggroll) and lots of users installing these forks when all it would have taken to get the same result would be to make certain DLLs accessible to official Proton.

[Galcian79]

Well, for what it matters, Valve should allow to use custom wine builds with Steam games. But now, with new Steam Runtime Soldier, it has become very hard to achieve, if even possible.