winhttp.dll: Prefer native,builtin to ease modding

[aldelaro5]

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

Proton 9.0 experimental introduced a change that sets dinput8.dll to prefer the native version. This allows mods that uses it as an entrypoint to not have to tell winecfg or steam's launch parameter to prefer to it as a native version which helps mods installation. Commit: ValveSoftware/wine@09af566

However, I think this list of dll names can be expanded. This particularly becomes important for me because I deal with a very popular unity games modloader called BepInEx: https://github.com/BepInEx/BepInEx . I would like to at the bar minimum have "winhttp.dll`, but ideally have also "version.dll" which are entrypoints used by unity doorstop: https://github.com/NeighTools/UnityDoorstop

Justification [optional]

As far as I know, most of the Unity modding ecosystem involves 2 mod loaders solutions:

• BepInEx (uses the unity doorstop entrypoint mentioned above)
• Melonloader (uses their own entrypoint that relies on a similar behavior for "version.dll")

These 2 loaders are used everywhere. A couple of examples of game communities that heavily relies on them (with links to instructions about the winhttp.dll quirk):

• Among Us
• Risk of Rain 2
• Lethal Company
• Valheim
• Subnautica
• Inscryption

And there's many more...probably hundreds. Both mod loaders specifically have to put in their setup instructions to change the default of wine/proton. Here's links containing those instructions:

• Bepinex: https://docs.bepinex.dev/articles/advanced/proton_wine.html
• Melonloader: https://melonwiki.xyz/#/README?id=windows-games-wineproton

And I am aware of many game specific communities that have to have similar mentions. The point I am making is this is an added installation step and if it was decided that it was okay to alleviate this step for "dinput8.dll", it seems to be reasonable to suggest to add it for "winhttp.dll" and "version.dll" as it would help a lot of mods users and developers to not have this extra installation step.

However, there's an even more compelling argument in my opinion to add more. The commit mentions it was originally done for "mod/ASI loaders", but if I check that loader's release page, I land on a list of supported dll names: https://github.com/ThirteenAG/Ultimate-ASI-Loader/releases/tag/v7.7.0

Not only are winhttp.dll and version.dll both present, but I also see common ones that are used for entrypoints such as dsound.dll. I think this list can be comprehensive because it seems to be relatively representative of what I typically see as common entrypoints. While I only personally ask for winhttp.dll (and optionally version.dll), any other appearing in this list seems to be safe bets to me, but I haven't personally encountered them.

Risks [optional]

This is a bit awkward for me to describe because I haven't used wine intensively enough to know if there are risks to expand this list, but what I do know is that the reason this is required for these modding setups is because it better reflects the Windows's default behavior. I actually don't know why the default on Wine is to deviate from this behavior so it's a bit hard for me to say how risky it is to change it in these cases, but what I do know is that specifically for winhttp.dll and version.dll, I haven't seen cases in which it broke someone's game.

References [optional]

I found an issue pertaining to the original motivation for doing this for "dinput8.dll": #7974

Sidenote: I was told on bluesky by @Plagman to "send request [their] way" so since I am opening an issue about it, I might as well tag them here.

[kisak-valve]

Hello @aldelaro5, this feature request should be scoped to evaluating a single dll, with known frameworks and games that would benefit from the change. The intent of structuring the request this way is so that Proton dev(s) can give a straight answer if Proton can be adjusted to have native,builtin with that specific dll without side effects.

For tracking purposes, this feature request will only focus on the first requested dll (winhttp.dll).

[aldelaro5]

Hello @aldelaro5, this feature request should be scoped to evaluating a single dll, with known frameworks and games that would benefit from the change. The intent of structuring the request this way is so that Proton dev(s) can give a straight answer if Proton can be adjusted to have native,builtin with that specific dll without side effects.

For tracking purposes, this feature request will only focus on the first requested dll (winhttp.dll).

Sounds good, I have informed the melonloader devs about this if they wish to open a separate issue about "version.dll" as they are more familiar than I about this loader.

[BipB0p]

I'll rewrite my message, I don't know if it's been adopted if it will work for all games or only selected games, but rain world requires the command for absolutely all workshop mods (#1230 (comment))

[Tiagoquix]

I totally agree with this request!

And I didn't even know that mine was accepted. Thanks for the info!

I think that having all of the Ultimate ASI Loader DLL names as native, then built-in isn't a huge risk because:

A) the user needs to install such custom DLLs for loading mods, or;
B) no DLL is loaded, even with the overrides, or;
C) the built-in DLLs are already loaded even without the n,b override, so it wouldn't make any difference.

The only problem I can see here is if a specific DLL always needs to be built-in-only, and this may be a reason not to prefer native in such cases. But I believe none of them need to be.

As I said in my other request about risks:

I don't see any possible risks if no ASI file is loaded. On Windows, if you install Ultimate ASI Loader and don't use any ASI plugins then there's no risk involved.

Regarding winhttp.dll specifically: I also had some multiplayer mods that I needed to add an override for it.

[Tiagoquix]

Relevant for this issue: see https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82668 for Wine devs talking about native DLL overrides.