Recently when I've tried to set a dll override to native, it wouldn't work if the native dll was in the windows\system directory. When I moved the dll to the folder that contained the executable, then the override was honored. Is this a regression, expected behavior, or an error on the part of the user?
On Wed, 8 Sep 2004 00:08:36 -0400 (EDT), Peter Petrakis voodoo@alphadriven.org wrote:
Hello All,
Citing this email from way back in 2000.
http://www.mail-archive.com/wine-devel%40winehq.com/msg00914.html
Talks about a crash when capture.exe is run from the orcad suite. I'm using orcad lite 9.2 (student edition), I can get everything to work except capture. I've upgraded to the latest rpm availble for suse 9.1 (wine-20040716-0.1, x86) but the problem remains.
I tried some troubleshooting which included getting the actual w32sys dll and issuing an override, which seems to be ignored. I also destroyed the symlink that aliased aforementioned library to libw32skml. It still crashes. For whatever reason it is not honoring the override. The relevant config section is the following:
[DllOverrides] ; some dlls you may want to change "oleaut32" = "builtin, native" "ole32" = "builtin, native" "comdlg32" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "advapi32" = "builtin, native" "w32sys" = "native, builtin" "w32skrnl" = "native, builtin" "msvcrt" = "native, builtin" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msi" = "native, builtin" "d3drm" = "native, builtin" "d3dxof" = "native, builtin" "dpnhpast" = "native, builtin" ; you can specify applications too ; this one will apply for all notepad.exe ;"*notepad.exe" = "native, builtin" ; this one will apply only for a particular file ;"C:\windows\regedit.exe" = "native, builtin" ; default for all other dlls "*" = "builtin, native"
[AppDefaults\capture.exe\DllOverrides] "w32sys" = "native"
Some debugging info,
petrakis@prin-92:~/.wine/fake_windows/Program Files/OrcadLite/Capture> export WINEDEBUG=+dll petrakis@prin-92:~/.wine/fake_windows/Program Files/OrcadLite/Capture> wine capture.exe trace:dll:fill_init_list (krnl386.exe) - START trace:dll:fill_init_list (krnl386.exe) - END trace:dll:fill_init_list (system.drv) - START trace:dll:fill_init_list (system.drv) - END trace:dll:fill_init_list (gdi.exe) - START trace:dll:fill_init_list (gdi.exe) - END trace:dll:fill_init_list (user.exe) - START trace:dll:fill_init_list (user.exe) - END trace:dll:fill_init_list (keyboard.drv) - START trace:dll:fill_init_list (keyboard.drv) - END trace:dll:fill_init_list (mmsystem.dll) - START trace:dll:fill_init_list (mmsystem.dll) - END trace:dll:NE_CallDllEntryPoint Calling mmsystem.dll DllEntryPoint, cs:ip=1187:0ac1 err:module:load_builtin_dll loaded .so for L"W32SYS.DLL" but got L"w32skrnl.dll" instead - probably 16-bit dll fixme:ole:CoRegisterMessageFilter stub wine: Unhandled exception (thread 0021), starting debugger... trace:dll:fill_init_list (krnl386.exe) - START trace:dll:fill_init_list (krnl386.exe) - END trace:dll:fill_init_list (system.drv) - START trace:dll:fill_init_list (system.drv) - END Usage: winedbg [--auto] [--gdb] cmdline
I'm very curious that the patch mentioned or something like it never made it into the source tree. I will integrate it myself the weekend (or as soon as friday) and see for myself. If this patch can work, I could switch ALOT of EE and CSE students over to Linux. Is there a work around that does not require a rebuild? Thanks in advance.
Peter