vitamin wrote: > > 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. Ah, I see what's the idea is now, thanks. vitamin wrote: > > 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 see. Also (lust wondering), what (how big) would be overhead if that wrapper (with renamed wine lib) would be used always (e.g. on all applications)?
