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 <[EMAIL PROTECTED]> 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, > > [EMAIL PROTECTED]:~/.wine/fake_windows/Program Files/OrcadLite/Capture> > export WINEDEBUG=+dll > [EMAIL PROTECTED]:~/.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 > > -- James Hawkins
