First: what is possible search path for builtin libraries (.dll.so) besides system-wide ?/usr/lib/wine?? Adding it to LD_LIBRARY_PATH didn't help? (I'm using debian version from winehq repository right now) Second: Is it possible to use wrapper of ?d3d8?? (morrowind graphics enhancer's). E.g. use native d3d8.dll which would wrap around builtin d3d8 of wine?
HoverHell wrote:> First: what is possible search path for builtin libraries (.dll.so) besides system-wide ?/usr/lib/wine??No, this is by design. All libraries go into one place. That lets multiple copies of Wine run without any problems. HoverHell wrote:> Second: Is it possible to use wrapper of ?d3d8?? (morrowind graphics enhancer's). E.g. use native d3d8.dll which would wrap around builtin d3d8 of wine?No. These have totally different interface into video driver. Wine uses OpenGL, while native talk directly to the video driver.
Gert van den Berg wrote:> 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)Wine always prefers it's own (built-in) dlls over natives except for few "stub" dlls - mostly placeholder dlls. This is done on purpose. And all discussions about changing that lead to - "yes we want it that way for number of reasons (....)". And there are even bugs filed for apps that have their own dll with the name identical to the built-in. But the dll have nothing to do with each-other. So the app crashes trying to use wrong dll. Same for Office 2005+ and it's "special" riched32.dll. So in short - no it won't be fixed any time soon. You have to hack Wine/wrpaper dll to make it do what you want. And if you don't have source - well you can hack it with hexedit :-)