On Sun, Mar 8, 2009 at 9:17 PM, vitamin wrote: > > HoverHell wrote: >> >> As far as I understand, wrapping d3d8.dll calls original d3d8.dll, so it doesn't matter what interface to video driver underlaying one uses. >> Which means it should be theoretically possible… >> E.g. wrapping native library isn't the d3d8.dll from windows distribution, but rather (opensourced) wrapper for modifying one specific game ( http://morrgraphext.wiki.sourceforge.net/Technical+Information ) > > I see. Well that's tricky because Wine loads either built-in or native version of dll. But not both. So if you say override d3d8 to be native, it won't load the built-in one. You can try to see what happens. > > Yeah it does exactly what I thought - places it's wrapper dlls into current directory (which means nothing for Wine). Then uses LoadLibrary to load the "real" dll from the system dir. Which won't work on Wine - those are "fake" dlls and Wine will still revert to loading whatever override order preference is. > > The only way I can think of getting around this is renaming Wine's d3d8 (or creating a copy). Then overriding the d3d8 as native. Of course that will require wrapper modification to load the renamed library. > I assume the wsock32 wrappers for emulating IPX over UDP does the same... Is there any way to checking whether this (A DLL with the same name as a "standard" one in die application directory is trying to load the DLL from its normal location) is what happens? (If I do not have access to the source code if the DLL) WINEDEBUG=loadll does not seem to give sufficient output. Relevant threads: http://forum.winehq.org/viewtopic.php?p=18936 http://forum.winehq.org/viewtopic.php?p=15853 The HOWTO on the AppDb mentions that forcing an override for wsock32 works, but I was unable to see any games (on my LAN) when using the override. AppDb page: http://appdb.winehq.org/objectManager.php?sClass=version&iId=252 Gert
