[Wine] Couple DLL problems

Gert van den Berg wine-users at mohag.net
Mon Mar 9 13:46:04 CDT 2009

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:

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:


More information about the wine-users mailing list