[Wine] Re: Couple DLL problems

[vitamin]

HoverHell wrote:
> 
> vitamin wrote:
> > No, this is by design. All libraries go into one place. That lets multiple copies of Wine run without any problems.
> 
> Err… Doesn't that mean that 1. multiple copies with different versions/variations of some builtin library have to be configured for different paths at compiletime, and 2. user can't install some library for himself (by default) without root access?

I meant to say Wine looks for libraries in the directory relative to where it's started from. So you can have the full set of libraries in one place. If you need custom Wine, you'll have to recompile it all and install it anywhere user has access to. Or even run it directly from the source tree.


HoverHell wrote:
> 
> vitamin wrote:
> > 
> > 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.
> 
> 
> 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.