[Bug 43727] New: native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

            Bug ID: 43727
           Summary: native dlls exists in the same exe directory wont
                    first load before builtin same name dlls
           Product: Wine
           Version: 2.10
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: wine-bugs(a)winehq.org
          Reporter: gamiljydcome(a)gmail.com
      Distribution: ---

native dlls such as riched20 msvcp90 msvcr90, if copy into the same directory
with the exe to run, wont default first load before builtin dlls any more. 

before wine1.9.x dont have this problem. i always load native dlls in this way,
its simple, and easy to compare with builtin dlls. 

does wine2.x drop this feature?

Regards.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |o.dierick(a)piezo-forte.be

--- Comment #1 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> ---
For dlls that have a Wine implementation, you have to set a dll override in
winecfg to native, builtin (or native only), if you want the native dll to load
when present.
Otherwise it's the builtin dll that is loaded.

It has always been so, as far as I can recall.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

Austin English <austinenglish(a)gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |austinenglish(a)gmail.com

--- Comment #2 from Austin English <austinenglish(a)gmail.com> ---
(In reply to Olivier F. R. Dierick from comment #1)
> For dlls that have a Wine implementation, you have to set a dll override in
> winecfg to native, builtin (or native only), if you want the native dll to
> load when present.
> Otherwise it's the builtin dll that is loaded.
>
> It has always been so, as far as I can recall.

Actually, it depends on the value of DLL_WINE_PREATTACH (true/false), which
varies for each dll. Generally, stub dlls set it to false (so native is
preferred), but dlls with actual implementations prefer builtin.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #3 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> ---
Indeed, riched20 and msvc* have quite evolved since wine 1.8.x.

(In reply to gamiljydcome from comment #0)
> native dlls such as riched20 msvcp90 msvcr90, if copy into the same
> directory with the exe to run, wont default first load before builtin dlls
> any more.

Setting DLL overrides to "native, builtin" for those DLLs will work that way.

Since this is not really a bug report, I suggest to mark the bug as resolved
fixed if your question has been answered (or invalid if you want to be strict).

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #4 from Rosanne DiMesio <dimesio(a)earthlink.net> ---
> Actually, it depends on the value of DLL_WINE_PREATTACH (true/false), which
> varies for each dll. Generally, stub dlls set it to false (so native is
> preferred), but dlls with actual implementations prefer builtin.

The description specifically mentions riched20, msvcr90, and msvcp90. Wine has
preferred builtin riched20 for as long as I've been using it; that's the reason
for bug 14980. As for msvcr90 and msvcp90, builtin has been preferred for those
since 2013-02-18 (commits 5d88f780dd4bbbde0ff27075b58321d7347f6d4b and
cfec148b8baeb86ee9d775f9cf527b80e043f5a4). So the OR couldn't have simply
copied those specific dlls to the program directory and have them be preferred
without setting an override in 1.9.x as claimed, at least not with plain Wine. 

IMO, this bug is invalid.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #5 from gamiljydcome(a)gmail.com ---
copy native riched20, msvc*, d3dx9_* to application directory, run exe with env
WINEDLLOVERRIDES="xxx=n,b", wine2.x still load builtin version from
c:\windows\system32.

i traced native riched20 loading proccess by run a exe with WINEDLLOVERRIDES,
trace log call tell native riched20 found in app directory, But finally only
load builtin dll from c:\windows\system32.

my submitted problem may not be a bug, but it's a useful feature for some app
just need one or two native dll.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #6 from gamiljydcome(a)gmail.com ---
i suggest if native dll override by winecfg or env WINEDLLOVERRIDES, then wine
loading the native dll from "app directory; env WINEPATH;
c:\windows\system32;...".

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #7 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> ---
> From the wiki[1] (may be outdated):

---
DLLs usually get loaded in the following order:

   1. The directory the program was started from.
   2. The current directory.
   3. The Windows system directory.
   4. The Windows directory.
   5. The PATH variable directories.
-----

[1] https://wiki.winehq.org/Wine_User%27s_Guide#DLL_Overrides

Make sure the DLLs are in one of this location.
The easy way is to cd into the directory where the DLLs are.

(In reply to gamiljydcome from comment #5)
> i traced native riched20 loading proccess by run a exe with
> WINEDLLOVERRIDES, trace log call tell native riched20 found in app
> directory, But finally only load builtin dll from c:\windows\system32.

Please attach the trace log to this bug report.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #8 from gamiljydcome(a)gmail.com ---
copy native msls31 riched20 dll to the exe directory, only enable native
version, start command is: 

WINEDEBUG=+all WINEDLLOVERRIDES="msls31,riched20=n"
WINEPREFIX=~/tmpfs/wine-test wine Thunder.exe &> mylog

the app will abort due to not load native riched20 from app directory.
following output logs from "grep -i rcihed mylog":

-----------------------------------------
64436.047:002a:002b:Call KERNEL32.GetModuleHandleW(009ccef0 L"RICHED20.dll")
ret=008eb30d
64436.047:002a:002b:trace:actctx:RtlFindActivationContextSectionString 00000001
(null) 2 L"RICHED20.dll" 0x34e220
64436.048:002a:002b:trace:file:RtlDosPathNameToNtPathName_U
(L"Z:\\tmp\\Thunder\\Program\\RICHED20.dll",0x34e0d8,(nil),(nil))
64436.048:002a:002b:trace:file:RtlGetFullPathName_U
(L"Z:\\tmp\\Thunder\\Program\\RICHED20.dll" 520 0x34de78 (nil))
64436.050:002a:002b:trace:file:wine_nt_to_unix_file_name
L"\\??\\Z:\\tmp\\Thunder\\Program\\RICHED20.dll" ->
"/home/jiangyd/tmpfs/wine-test/dosdevices/z:/tmp/Thunder/Program/riched20.dll"
64436.052:002a:002b:trace:file:RtlGetFullPathName_U
(L"Z:\\tmp\\Thunder\\Program\\RICHED20.dll" 256 0x34e2c0 0x34e20c)
64436.053:002a:002b:trace:module:LdrGetDllHandle L"RICHED20.dll" -> (nil) (load
path
L"Z:\\tmp\\Thunder\\Program;.;C:\\windows\\system32;C:\\windows\\system;C:\\windows;/home/jiangyd/wine/kvm-win2003/xp\8f6f\4ef6/\5907\7528dll;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem")
64436.053:002a:002b:Call shlwapi.PathAppendW(0034e4d8
L"C:\\windows\\system32",009ccf0c L"RICHED20.dll") ret=0089761f
64436.053:002a:002b:trace:shell:PathAppendW
(L"C:\\windows\\system32",L"RICHED20.dll")
64436.053:002a:002b:trace:shell:PathIsUNCW (L"RICHED20.dll")
64436.053:002a:002b:trace:shell:PathCombineW
(0x34e4d8,L"C:\\windows\\system32",L"RICHED20.dll")
64436.053:002a:002b:trace:shell:PathIsRelativeW (L"RICHED20.dll")
64436.053:002a:002b:trace:shell:PathCanonicalizeW
(0x34e4d8,L"C:\\windows\\system32\\RICHED20.dll")
64436.053:002a:002b:Call KERNEL32.GetFullPathNameW(0034e4d8
L"C:\\windows\\system32\\RICHED20.dll",00000104,0034e084,0034e074) ret=00402af2
64436.053:002a:002b:trace:file:RtlGetFullPathName_U
(L"C:\\windows\\system32\\RICHED20.dll" 520 0x34e084 0x34e074)
64436.053:002a:002b:Call msvcr90._wcslwr(0034e28c L"RICHED20.dll") ret=00402b23
64436.055:002a:002b:Call shlwapi.PathFindExtensionW(0034e4d8
L"C:\\windows\\system32\\RICHED20.dll") ret=00402b95
64436.055:002a:002b:trace:shell:PathFindExtensionW
(L"C:\\windows\\system32\\RICHED20.dll")
64436.057:002a:002b:Call KERNEL32.LoadLibraryExW(0034e4d8
L"C:\\windows\\system32\\RICHED20.dll",00000000,00000000) ret=00402a31
64436.058:002a:002b:trace:module:load_dll looking for
L"C:\\windows\\system32\\RICHED20.dll" in
L"Z:\\tmp\\Thunder\\Program;.;C:\\windows\\system32;C:\\windows\\system;C:\\windows;/home/jiangyd/wine/kvm-win2003/xp\8f6f\4ef6/\5907\7528dll;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem"
64436.058:002a:002b:trace:file:RtlDosPathNameToNtPathName_U
(L"C:\\windows\\system32\\RICHED20.dll",0x34e1c0,0x34e1bc,(nil))
64436.058:002a:002b:trace:file:RtlGetFullPathName_U
(L"C:\\windows\\system32\\RICHED20.dll" 520 0x34df48 0x34e1bc)
64436.059:002a:002b:trace:ntdll:FILE_CreateFile handle=0x34e264 access=80100000
name=L"\\??\\C:\\windows\\system32\\RICHED20.dll" objattr=00000040 root=(nil)
sec=(nil) io=0x34e1c8 alloc_size=(nil) attr=00000000 sharing=00000005 disp=1
options=00000060 ea=(nil).0x00000000
64436.384:002a:002b:trace:file:wine_nt_to_unix_file_name
L"\\??\\C:\\windows\\system32\\RICHED20.dll" ->
"/home/jiangyd/tmpfs/wine-test/dosdevices/c:/windows/system32/riched20.dll"
002b: create_file( access=80100000, sharing=00000005, create=1,
options=00000060, attrs=00000000,
objattr={rootdir=0000,attributes=00000040,sd={},name=L""},
filename="/home/jiangyd/tmpfs/wine-test/dosdevices/c:/windows/system32/riched20.dll"
)
64436.388:002a:002b:trace:module:get_load_order looking for
L"C:\\windows\\system32\\RICHED20.dll"
64436.389:002a:002b:trace:module:get_load_order_value got environment n for
L"RICHED20"
64436.390:002a:002b:trace:module:load_dll
L"C:\\windows\\system32\\RICHED20.dll" is a fake Wine dll
64436.390:002a:002b:warn:module:load_dll Failed to load module
L"C:\\windows\\system32\\RICHED20.dll"; status=c0000135
-----------------------------------------

copy them to c:\windows\system32 runs ok with the same command.

more complete log part from mylog as attachment.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #9 from gamiljydcome(a)gmail.com ---
Created attachment 59229
  --> https://bugs.winehq.org/attachment.cgi?id=59229
trace.log

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #10 from Alexandre Julliard <julliard(a)winehq.org> ---
(In reply to gamiljydcome from comment #8)
> 64436.057:002a:002b:Call KERNEL32.LoadLibraryExW(0034e4d8
> L"C:\\windows\\system32\\RICHED20.dll",00000000,00000000) ret=00402a31

The app is explicitly asking for c:\windows\system32\riched20.dll, so that's
what it gets. I don't see any bug here.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #11 from gamiljydcome(a)gmail.com ---
(In reply to Alexandre Julliard from comment #10)
> The app is explicitly asking for c:\windows\system32\riched20.dll, so that's
> what it gets. I don't see any bug here.

if the app absolutely link with c:\windows\system32\riched20.dll runs in
ms-windows, that's fine. 

wine need to follow the rule?

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

Alexandre Julliard <julliard(a)winehq.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> ---
(In reply to gamiljydcome from comment #11)
> (In reply to Alexandre Julliard from comment #10)
> > The app is explicitly asking for c:\windows\system32\riched20.dll, so that's
> > what it gets. I don't see any bug here.
>
> if the app absolutely link with c:\windows\system32\riched20.dll runs in
> ms-windows, that's fine.
>
> wine need to follow the rule?

Yes, Wine has to implement the Windows rules.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #13 from gamiljydcome(a)gmail.com ---
i think to overrided native dlls, follow wine's loading order even if app link
a dll with absolutely path is better.

besides, i suggest to wine's dll loading order, 5.The PATH variable
directories(env WINEPATH?) has priority over 3.The Windows system directory.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #14 from Alexandre Julliard <julliard(a)winehq.org> ---
(In reply to gamiljydcome from comment #13)
> i think to overrided native dlls, follow wine's loading order even if app
> link a dll with absolutely path is better.
>
> besides, i suggest to wine's dll loading order, 5.The PATH variable
> directories(env WINEPATH?) has priority over 3.The Windows system directory.

Like I said, we have to follow the Windows rules. If you want to use a native
dll you have to put it in the directory where it would have been loaded on
Windows; that can be a dozen different places depending on what the app
requests. See
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).a...
if you want the gory details.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

--- Comment #15 from gamiljydcome(a)gmail.com ---
ok, windows rules is first.

thanks for help, guys.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 43727] native dlls exists in the same exe directory wont first load before builtin same name dlls

https://bugs.winehq.org/show_bug.cgi?id=43727

Austin English <austinenglish(a)gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #16 from Austin English <austinenglish(a)gmail.com> ---
Closing.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.