How to change Wine DLL search path for "built-in" DLLs?

Vladimir Panteleev vladimir at thecybershadow.net
Sat Apr 9 10:47:22 CDT 2016


On Sat, Apr 9, 2016 at 2:29 PM, Stefan Dösinger
<stefandoesinger at gmail.com> wrote:
> You can set WINEDLLOVERRIDES to set overrides without editing stuff in winecfg or the registry.

Thanks Stefan. WINEDLLOVERRIDES, combined with putting the DLLs in
system32/syswow64 or the EXE directory, works, however only when
WINEDLLOVERRIDES is in the environment when Wine is started. Setting
it from within a Windows program running under Wine seems to have no
effect, therefore I can't use this solution.

> If the DLL overrides don't work it's possible that some other piece is missing. You can use WINEDEBUG=loaddll,module to find out what the loader is doing.

With WINEDEBUG, I see the following:

trace:module:load_dll looking for L"MSVCR120.dll" in
L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program
Files (x86)\\Microsoft Visual Studio
12.0\\VC\\bin\\amd64;.;C:\\windows\\system32;C:\\windows\\system;C:\\windows;Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\windows\\system64;Z:\\home\\vladimir\\work\\D"...

(Great, it's looking in the right places. Not in PATH but I can place
it in the first directory (the EXE directory, since it's not a system
one.)

trace:module:get_load_order looking for
L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program
Files (x86)\\Microsoft Visual Studio
12.0\\VC\\bin\\amd64\\MSVCR120.dll"

(Not sure what this implies if anything.)

trace:module:get_load_order got hardcoded default for
L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program
Files (x86)\\Microsoft Visual Studio
12.0\\VC\\bin\\amd64\\MSVCR120.dll"

("Hardcoded default"?)

trace:module:load_builtin_dll Trying built-in
L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program
Files (x86)\\Microsoft Visual Studio
12.0\\VC\\bin\\amd64\\MSVCR120.dll"
warn:module:load_builtin_dll failed to load .so lib for builtin
L"Z:\\home\\vladimir\\work\\Digger\\work-wine\\dl\\vs2013-community\\Program
Files (x86)\\Microsoft Visual Studio
12.0\\VC\\bin\\amd64\\MSVCR120.dll":
/home/vladimir/.wine/dosdevices/z:/home/vladimir/work/Digger/work-wine/dl/vs2013-community/Program
Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/msvcr120.dll:
invalid ELF header

(It seems to try to load the DLL in the EXE's directory as a built-in,
even when it's native. Understandably, it fails.)

trace:module:load_builtin_dll Trying built-in L"MSVCR120.dll"

(It seems to fall back to its own internal built-in version, even
after I have removed it from system32/system64.)

I don't really see a way out...

> The even better solution would be to implement the missing functions :-)

Yep, I've discovered many things that could be fixed or improved.
However, for this particular endeavor, I need to target existing Wine
versions.

> Am 09.04.2016 um 01:22 schrieb Vladimir Panteleev <vladimir at thecybershadow.net>:
>
>> Thanks Theodore. As I have mentioned, I have already tried DLL
>> overrides, which did not provide the desired effect. Also, as I have
>> mentioned, I'm looking for a programmatic solution, without involving
>> user intervention.
>>
>> On Fri, Apr 8, 2016 at 11:21 PM, Vladimir Panteleev
>> <vladimir at thecybershadow.net> wrote:
>>> Thanks Theodore. As I have mentioned, I have already tried DLL
>>> overrides, which did not provide the desired effect. Also, as I have
>>> mentioned, I'm looking for a programmatic solution, without involving
>>> user intervention.
>>>
>>> On Fri, Apr 8, 2016 at 11:19 PM, Theodore Dubois <tblodt at icloud.com> wrote:
>>>> Use DLL overrides. Open winecfg, go to the Libraries tab, type msvcr120, click add, click edit, click native, click ok.
>>>>
>>>> ~Theodore
>>>>
>>>>> On Apr 8, 2016, at 2:52 PM, Vladimir Panteleev <vladimir at thecybershadow.net> wrote:
>>>>>
>>>>> (reposting from wine-users, which seems to be dead)
>>>>>
>>>>> I'm trying to get the VS2012 C++ compiler (cl.exe) running under Wine
>>>>> - stand-alone, as a component for a different larger project. The
>>>>> project works fine on Windows without affecting any global system
>>>>> settings or files (i.e. it unpacks DLLs etc. to private subdirs
>>>>> instead of installing them system-wide). I'd like it to "just work"
>>>>> under Wine as well, without user intervention or persistent
>>>>> modifications to bottle settings or system files.
>>>>>
>>>>> Wine has a msvcr120.dll, however it is incomplete, at least as far as
>>>>> cl.exe is concerned:
>>>>>
>>>>> wine: Call from 0x7b44ee37 to unimplemented function
>>>>> msvcr120.dll.??0reader_writer_lock at Concurrency@@QEAA at XZ, aborting
>>>>> Internal Compiler Error in
>>>>> Z:\home\vladimir\work\Digger\work-wine\dl\vs2013-community\Program
>>>>> Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\cl.exe.  You
>>>>> will be prompted to send an error report to Microsoft later.
>>>>>
>>>>> The problem is that it attempts to load its builtin DLL even if I
>>>>> place the native Microsoft's DLL in PATH before system32/syswow64.
>>>>> WINEDLLPATH seems to have no effect, and adding a DLL override has no
>>>>> effect other than changing whether it loads Wine's DLL on fails to
>>>>> load a DLL at all (even though it's in PATH!). Yes, the model
>>>>> (bitness) is correct.
>>>>>
>>>>> I remember reading somewhere that Wine uses the value of PATH from the
>>>>> registry. I guess I could also just delete or overwrite Wine's DLL in
>>>>> system32/syswow64. But is it possible to change the DLL search path
>>>>> for one Wine invocation, without any permanent modifications to the
>>>>> bottle?
>>>>>
>>>>> Partially related, but I noticed that Wine does not skip over DLLs of
>>>>> wrong bitness as Windows does. Instead, the program fails to
>>>>> initialize. This means you can't add 32-bit and 64-bit DLL directories
>>>>> to PATH and let the programs' bitness sort out which to use. That's
>>>>> definitely a bug I guess.
>>>>>
>>>>>
>>>>
>>
>>
>
>
>
>



More information about the wine-devel mailing list