Prefer native versions of various DLLs

[Tiagoquix]

This PR aims to address ValveSoftware/Proton#8308.

A previous issue of mine was already addressed by this commit.

This PR extends the same effects of that commit to all various other DLLs that can be used by https://github.com/ThirteenAG/Ultimate-ASI-Loader/releases/latest (excluding non-existent DLLs under Wine dlls folder such as the Bink ones).

Caveats

This approach, in general, has already been rejected upstream. See the discussion in https://gitlab.winehq.org/wine/wine/-/merge_requests/6527 for more details (specifically, this comment).

From what I understand, upstream plans to enhance the DLL loading mechanism to solve those cases of native vs. built-in. However, for the time being, this should bring a quality-of-life change to gamers that want to add mods to their games.

Please see the aforementioned Proton issues and their comments for more details regarding security risks.

Thanks for your attention.

Edit: to complement, this is the opinion of Paul Gofman, responsible for the "prefer native dinput8.dll" commit in this repository:

my opinion is that these overrides suck, we'd better have a better way to detect but noone came up with it yet. Maybe we can choose something very wide used to add, not sure if that is winhttp.

[ivyl]

This is a bit too much of a scattershot approach IMO. d3d* dlls are already preferring native due to the proton script. This will cause some troubles with trying to use wined3d if dxvk/vkd3d-proton dlls are around - it's set to prefer builtin and controlled by the script for a reason.

For everything else we should still be very careful - this needs to check if there are things out there in the wild shipping those DLLs via redists or along the game exes. There's a huge chance that a real (i.e. not mod injector) DLL would not work at all.

I would enable it for only very popular modding methods and make sure they work at all before flipping the switch.

[Tiagoquix]

There's a huge chance that a real (i.e. not mod injector) DLL would not work at all.

Do you mean a game can ship an DLL that Proton would prefer the built-in version to be loaded instead? I guess that's possible, but unlikely to cause problems in my opinion.

If a game ever ships a specific DLL that Wine also ships, I guess it would be to perform certain actions related to the executable and then leave the rest to be done by the system DLL.

However, I agree that we should be cautious and only enable more popular ones.

From the top of my head, I believe those ones are safe and the most popular to enable:

• ddraw.dll: used by some compatibility projects for older games (such as https://github.com/narzoul/DDrawCompat and https://github.com/FunkyFr3sh/cnc-ddraw; the first one isn't supported on Wine, however).
• dsound.dll: used by Ultimate ASI Loader on some modern games (I can only recall GTA 5 at the moment) as an alternative name. I recall having to override it for the GTA 5 Enhanced patch here.
• winhttp.dll: used by multiplayer games to enable some additional community modification. It is also what the issue at winhttp.dll: Prefer native,builtin to ease modding Proton#8308 is requesting. I am not aware of any game that ships this by default. I am aware of some older games that ship network-related DLLs, but the official servers are down, so the DLL is useless in those cases. I play one game that has a community mod for an alternative multiplayer game mode which requires an override for this DLL (it uses BepInEx, the same name mentioned in the Proton issue tracker).

Some that may be safe, but I am not exactly sure:

• version.dll: generic name, but not sure if it is safe to enable. So far, I've only needed to override it for this project, but it no longer works anymore. I don't recall seeing any games (from those that I've played) shipping a DLL with this name.
• xlive.dll: I only know of this mod for GTA 4 that uses it. If I recall it correctly, it can also be used for some other games. Should be safe to override, as I believe it is only related to Games for Windows Live (GFWL) which has been shut down entirely some time ago. I believe real Xbox Live DLLs use another name.

P.S.: this is the only commit for this PR I've made originally. Not sure how the PR got this messy: Tiagoquix@544c502

[Tiagoquix]

@ivyl Any comments about my previous comment? Thanks!