Re: wine/dlls/ntdll loadorder.c
On 28 Jul 2005 11:46:46 +0200, you wrote: > Rein Klazes <[EMAIL PROTECTED]> writes: > > > | trace:module:load_dll looking for L"comm.dll" in > > L"E:\\bin\\gt3\\GTWin;.;d:\\win98\\system;d:\\WIN98;d:\\windows;d:\\windows\\system;h:\\shared;r:\\x86\\Setup" > > | trace:module:MODULE_GetLoadOrderW looking for > > L"E:\\bin\\gt3\\GTWin\\comm.dll" > > | trace:module:open_app_key searching L"E:\\bin\\gt3\\GTWin\\comm" in > > L"Software\\Wine\\AppDefaults\\girotel.exe\\DllOverrides" > > | trace:module:MODULE_GetLoadOrderW got hardcoded default "b,n" for > > L"E:\\bin\\gt3\\GTWin\\comm.dll" > > | trace:module:load_dll Trying built-in L"E:\\bin\\gt3\\GTWin\\comm.dll" > > | warn:module:load_dll Failed to load module L"comm.dll"; status=c07b > > Are you sure you don't have an old symlink lying around? comm.drv > used to be named comm.dll, but it was renamed about 2 years ago. You are absolutely right, comm.dll.so was still existing in the local/lib/wine dir. From the date probably created during some regression testing recently. Rein.
Re: wine/dlls/ntdll loadorder.c
Peter Oberndorfer <[EMAIL PROTECTED]> writes: > It's a bit of both :-) > The dbghelp shipped with WinDbg has a SymSetParentWindow entry point which is > not (yet) available in wine. > So it catches fire when the function is called. > Adding a SymSetParentWindow stub is easy but shouldn't it load the > dbghelp.dll > in the app dir? Well no, that's what has changed, we are now respecting the config settings even for files in the app dir, so you have to explicitly configure it as native if that's what you want (but of course fixing the builtin is preferable). The idea is that the config should work the same way no matter where we load the dll from. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/dlls/ntdll loadorder.c
On Thursday 28 July 2005 23:14, Alexandre Julliard wrote: > Peter Oberndorfer <[EMAIL PROTECTED]> writes: > > Same thing happens here with WinDbg 6.5.3.7 which comes with dbghelp.dll > > in app directory. > > If you mean it fails to load dbghelp completely then that's a bug. If > it's loading the builtin dbghelp instead of the native then it's a > feature It's a bit of both :-) The dbghelp shipped with WinDbg has a SymSetParentWindow entry point which is not (yet) available in wine. So it catches fire when the function is called. Adding a SymSetParentWindow stub is easy but shouldn't it load the dbghelp.dll in the app dir? Or does dbghelp get some special treatment because it has ability to read other debug formats?) OllyDbg is another application that comes with newer dbghelp. I don' know if it is important but the dependency tree for windbg is: windbg ->dbgeng.dll(native dll in app dir) ->dbghelp windbg ->dbghelp Greetings Peter
Re: wine/dlls/ntdll loadorder.c
Peter Oberndorfer <[EMAIL PROTECTED]> writes: > Same thing happens here with WinDbg 6.5.3.7 which comes with dbghelp.dll in > app directory. If you mean it fails to load dbghelp completely then that's a bug. If it's loading the builtin dbghelp instead of the native then it's a feature -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/dlls/ntdll loadorder.c
On Thursday 28 July 2005 11:46, Alexandre Julliard wrote: > Rein Klazes <[EMAIL PROTECTED]> writes: > > | trace:module:load_dll looking for L"comm.dll" in > > | L"E:\\bin\\gt3\\GTWin;.;d:\\win98\\system;d:\\WIN98;d:\\windows;d:\\win > > |dows\\system;h:\\shared;r:\\x86\\Setup" > > | trace:module:MODULE_GetLoadOrderW looking for > > | L"E:\\bin\\gt3\\GTWin\\comm.dll" trace:module:open_app_key searching > > | L"E:\\bin\\gt3\\GTWin\\comm" in > > | L"Software\\Wine\\AppDefaults\\girotel.exe\\DllOverrides" > > | trace:module:MODULE_GetLoadOrderW got hardcoded default "b,n" for > > | L"E:\\bin\\gt3\\GTWin\\comm.dll" trace:module:load_dll Trying built-in > > | L"E:\\bin\\gt3\\GTWin\\comm.dll" warn:module:load_dll Failed to load > > | module L"comm.dll"; status=c07b > > Are you sure you don't have an old symlink lying around? comm.drv > used to be named comm.dll, but it was renamed about 2 years ago. Hi Same thing happens here with WinDbg 6.5.3.7 which comes with dbghelp.dll in app directory. Greetings Peter
Re: wine/dlls/ntdll loadorder.c
Rein Klazes <[EMAIL PROTECTED]> writes: > | trace:module:load_dll looking for L"comm.dll" in > L"E:\\bin\\gt3\\GTWin;.;d:\\win98\\system;d:\\WIN98;d:\\windows;d:\\windows\\system;h:\\shared;r:\\x86\\Setup" > | trace:module:MODULE_GetLoadOrderW looking for > L"E:\\bin\\gt3\\GTWin\\comm.dll" > | trace:module:open_app_key searching L"E:\\bin\\gt3\\GTWin\\comm" in > L"Software\\Wine\\AppDefaults\\girotel.exe\\DllOverrides" > | trace:module:MODULE_GetLoadOrderW got hardcoded default "b,n" for > L"E:\\bin\\gt3\\GTWin\\comm.dll" > | trace:module:load_dll Trying built-in L"E:\\bin\\gt3\\GTWin\\comm.dll" > | warn:module:load_dll Failed to load module L"comm.dll"; status=c07b Are you sure you don't have an old symlink lying around? comm.drv used to be named comm.dll, but it was renamed about 2 years ago. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/dlls/ntdll loadorder.c
On 27 Jul 2005 16:37:18 +0200, you wrote: > Rein Klazes <[EMAIL PROTECTED]> writes: > > > Girotel uses a 32 bit comm.dll located in the programs directory, which > > is also the current directory. After this change I need to add an dll > > override to load the program's comm.dll and not attempt the built-in > > comm.drv, which of course is not needed in Windows. > > > > Is this a regression or an intentional change in behavior? > > Since comm.drv is 16-bit and doesn't even have the same name, this > shouldn't be an issue at all. Could you please send me some traces > showing the problem? This is +relay,+module trace with a recent (few days old) cvs and no specific dll overrides: | 0009:Call kernel32.LoadLibraryA(7ff08e08 "comm.dll") ret=6c4008c2 | 0009:Call ntdll.RtlInitAnsiString(7ba5f378,7ff08e08 "comm.dll") ret=7bb0deff | 0009:Ret ntdll.RtlInitAnsiString() retval=0009 ret=7bb0deff | 0009:Call ntdll.RtlAnsiStringToUnicodeString(7be68bf8,7ba5f378,) ret=7bb0df98 | 0009:Ret ntdll.RtlAnsiStringToUnicodeString() retval= ret=7bb0df98 | 0009:Call ntdll.RtlInitUnicodeString(7ba5f37c,7be68c00 L"comm.dll") ret=7bb2a8ed | 0009:Ret ntdll.RtlInitUnicodeString() retval=0012 ret=7bb2a8ed | 0009:Call ntdll.RtlInitUnicodeString(7ba5f32c,7bb6fcc8 L"PATH") ret=7bb2a3ff | 0009:Ret ntdll.RtlInitUnicodeString() retval=000a ret=7bb2a3ff | 0009:Call ntdll.RtlQueryEnvironmentVariable_U(,7ba5f32c,7ba5f324) ret=7bb2a433 | 0009:Ret ntdll.RtlQueryEnvironmentVariable_U() retval=c023 ret=7bb2a433 | 0009:Call ntdll.RtlAllocateHeap(7bbd,,00c0) ret=7bb171ad | 0009:Ret ntdll.RtlAllocateHeap() retval=7bca3d90 ret=7bb171ad | 0009:Call ntdll.RtlQueryEnvironmentVariable_U(,7ba5f32c,7ba5f324) ret=7bb2a51a | 0009:Ret ntdll.RtlQueryEnvironmentVariable_U() retval= ret=7bb2a51a | 0009:Call ntdll.LdrLoadDll(7bca3d90 L"E:\\bin\\gt3\\GTWin;.;d:\\win98\\system;d:\\WIN98;d:\\windows;d:\\windows\\system;h:\\shared;r:\\x86\\Setup",,7ba5f37c,7ba5f35c) ret=7bb2a7fd | trace:module:load_dll looking for L"comm.dll" in L"E:\\bin\\gt3\\GTWin;.;d:\\win98\\system;d:\\WIN98;d:\\windows;d:\\windows\\system;h:\\shared;r:\\x86\\Setup" | trace:module:MODULE_GetLoadOrderW looking for L"E:\\bin\\gt3\\GTWin\\comm.dll" | trace:module:open_app_key searching L"E:\\bin\\gt3\\GTWin\\comm" in L"Software\\Wine\\AppDefaults\\girotel.exe\\DllOverrides" | trace:module:MODULE_GetLoadOrderW got hardcoded default "b,n" for L"E:\\bin\\gt3\\GTWin\\comm.dll" | trace:module:load_dll Trying built-in L"E:\\bin\\gt3\\GTWin\\comm.dll" | warn:module:load_dll Failed to load module L"comm.dll"; status=c07b | 0009:Ret ntdll.LdrLoadDll() retval=c07b ret=7bb2a7fd | 0009:Call ntdll.RtlFreeHeap(7bbd,,7bca3d90) ret=7bb171ed | 0009:Ret ntdll.RtlFreeHeap() retval=0001 ret=7bb171ed | 0009:Call ntdll.RtlNtStatusToDosError(c07b) ret=7bb2a83f | 0009:Ret ntdll.RtlNtStatusToDosError() retval=00c1 ret=7bb2a83f | 0009:Ret kernel32.LoadLibraryA() retval= ret=6c4008c2 Same trace, just with that patch reversed: | 0009:Call kernel32.LoadLibraryA(7ff08e08 "comm.dll") ret=6c4008c2 | 0009:Call ntdll.RtlInitAnsiString(7ba5f378,7ff08e08 "comm.dll") ret=7bb0deff | 0009:Ret ntdll.RtlInitAnsiString() retval=0009 ret=7bb0deff | 0009:Call ntdll.RtlAnsiStringToUnicodeString(7be68bf8,7ba5f378,) ret=7bb0df98 | 0009:Ret ntdll.RtlAnsiStringToUnicodeString() retval= ret=7bb0df98 | 0009:Call ntdll.RtlInitUnicodeString(7ba5f37c,7be68c00 L"comm.dll") ret=7bb2a8ed | 0009:Ret ntdll.RtlInitUnicodeString() retval=0012 ret=7bb2a8ed | 0009:Call ntdll.RtlInitUnicodeString(7ba5f32c,7bb6fcc8 L"PATH") ret=7bb2a3ff | 0009:Ret ntdll.RtlInitUnicodeString() retval=000a ret=7bb2a3ff | 0009:Call ntdll.RtlQueryEnvironmentVariable_U(,7ba5f32c,7ba5f324) ret=7bb2a433 | 0009:Ret ntdll.RtlQueryEnvironmentVariable_U() retval=c023 ret=7bb2a433 | 0009:Call ntdll.RtlAllocateHeap(7bbd,,00c0) ret=7bb171ad | 0009:Ret ntdll.RtlAllocateHeap() retval=7bca7628 ret=7bb171ad | 0009:Call ntdll.RtlQueryEnvironmentVariable_U(,7ba5f32c,7ba5f324) ret=7bb2a51a | 0009:Ret ntdll.RtlQueryEnvironmentVariable_U() retval= ret=7bb2a51a | 0009:Call ntdll.LdrLoadDll(7bca7628 L"E:\\bin\\gt3\\GTWin;.;d:\\win98\\system;d:\\WIN98;d:\\windows;d:\\windows\\system;h:\\shared;r:\\x86\\Setup",,7ba5f37c,7ba5f35c) ret=7bb2a7fd | trace:module:load_dll looking for L"comm.dll" in L"E:\\bin\\gt3\\GTWin;.;d:\\win98\\system;d:\\WIN98;d:\\windows;d:\\windows\\system;h:\\shared;r:\\x86\\Setup" | trace:module:MODULE_GetLoadOrderW looking for L"E:\\bin\\gt3\\GTWin\\comm.dll" | trace:module:open_app_key searching L"E:\\bin\\gt3\\GTWin\\comm" in L"Software\\Wine\\AppDefaults\\girotel.exe\\DllOverrides" | trace:module:MODULE_GetLoadOrderW got hardcoded path default "n,b" for L"E:\\bin\\gt3\\GTWin\\comm.dll" | trace:module:load_dll Trying native dll L"E:\\bin\\gt3\
Re: wine/dlls/ntdll loadorder.c
Rein Klazes <[EMAIL PROTECTED]> writes: > Girotel uses a 32 bit comm.dll located in the programs directory, which > is also the current directory. After this change I need to add an dll > override to load the program's comm.dll and not attempt the built-in > comm.drv, which of course is not needed in Windows. > > Is this a regression or an intentional change in behavior? Since comm.drv is 16-bit and doesn't even have the same name, this shouldn't be an issue at all. Could you please send me some traces showing the problem? -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/dlls/ntdll loadorder.c
On Thu, 7 Jul 2005 13:26:11 -0500, you wrote: > ChangeSet ID: 18748 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: [EMAIL PROTECTED] 2005/07/07 13:26:11 > > Modified files: > dlls/ntdll : loadorder.c > > Log message: > Use the same defaults for modules with and without an explicit path. Girotel uses a 32 bit comm.dll located in the programs directory, which is also the current directory. After this change I need to add an dll override to load the program's comm.dll and not attempt the built-in comm.drv, which of course is not needed in Windows. Is this a regression or an intentional change in behavior? Rein.
