protonscr

winhttp.dll: Prefer native,builtin to ease modding

protonopen Feature Request
ValveSoftware/Proton#8308 · opened 2024-12-11 by aldelaro5 · updated 2026-04-04 · 10 comments · github
Aaldelaro5 2024-12-11 github

Feature Request

I confirm:

  • [x] that I haven't found another request for this feature.
  • [x] 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: https://github.com/ValveSoftware/wine/commit/09af566a7fbaa075eaeaa76468c7344bdbeeafda

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:

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": https://github.com/ValveSoftware/Proton/issues/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.

Kkisak-valve maintainer 2024-12-11 github

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).

Aaldelaro5 2024-12-11 github

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.

BBipB0p 2024-12-12 github

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 (https://github.com/ValveSoftware/Proton/issues/1230#issuecomment-1399333631)

TTiagoquix 2024-12-17 github

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.

TTiagoquix 2024-12-17 github

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

Wwaspennator 2025-02-21 github

Would like to see this implemented some day, Elin needs this in order for workshop mods to actually work.

Edit: Made an individual report for Elin at #8522

Aaldelaro5 2025-11-13 github

It's been a while, has there been any news or triage about this?

It very much is still relevant for BepInEx, one of the 2 most popular Unity game modloader.

Wwaspennator 2025-11-13 github

Would still love to see winhttp native enabled by default like dinput8 was, since plenty of games have mods that need it to work, like Elin.

Same for winmm and other dlls

Aaldelaro5 2026-04-04 github

https://gitlab.winehq.org/wine/wine/-/commit/a31ec8da9572672e04ae46792a398da942649875

Saw this commit on wine recently

I been checking this. Since then, Wine 11.6 released and it's available on vanilla Arch Linux so I tested this.

I'm glad to say it appears to work! I use a winhttp.dll proxy on my custom modloader and I removed all manual override configured on my prefix, but it still resulted in the modloader kicking in.

So the big question now is will proton keep this change whenever proton 12 comes out (cause the next stable release of wine is next year for wine 12 which will have this commit).

Proton versions

Upstream links

DLLs