https://bugs.winehq.org/show_bug.cgi?id=53732
--- Comment #4 from varrok@gmail.com --- (In reply to Zeb Figura from comment #3)
(In reply to varrok from comment #2)
It worked, which confuses me to a great extent, as I don't know why it didn't work before. From my understanding, the default setting can be boiled to: "search wine's opengl32.dll, then if something is not present there, use the 3rd party one".
I thought that if I remove the wine's opengl32.dll (drive_c/Windows/system32/opengl32.dll and syswow64/opengl32.dll) it would fallback to reshade's dll, yet it produces a different outcome than your solution. Furthermore, if I then remove/rename the reshade's dll as well, the game would fail to launch, so surely it does access the reshade file.
I'll mark this as resolved, but an explanation would probably help me make fewer mistakes in the future.
The native/builtin logic only controls loading of the entire dll, not individual exports. If exports are missing from the DLL that's loaded, things will just fail. (We can't implement it the way you're thinking, either.)
Builtin DLLs are loaded regardless of the content of the DLL file on disk. In fact, builtin DLLs are never loaded from the prefix; they're always loaded from the install directory (e.g. in /usr/lib/) or from the build tree. The copy in the prefix only exists because some programs expect (some) libraries to exist on-disk and to match the in-memory image.
However, we don't load builtins if the file on disk is absent entirely. This is basically because programs expect this behaviour.
In essence you can think of it like transparently swapping out the on-disk DLL for the builtin one from the install/build directory if builtin load order is specified.
I really appreciate the explanation, thanks! It's all clear