Couple DLL problems

[HoverHell]

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?

[vitamin]

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.

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.

[HoverHell]

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?

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.ne ... nformation )

[vitamin]

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.

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.ne ... nformation )

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.

[HoverHell]

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.

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)?

[vitamin]

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)?

Depends on what that wrapper does and how.

You don't have to use it for every app. As I suggested made a copy with a different name (not outright rename it). Then for your app only override d3d8 to native.

[Gert van den Berg]

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.ne ... nformation )

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.p ... on&iId=252

Gert

[vitamin]

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

[Gert van den Berg]

On Tue, Mar 10, 2009 at 1:03 AM, vitamin <[email protected]> wrote:

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.

A third mode, emulating Windows' behaviour would be nice...
(native,builtin is fine for the riched issues, but something that
works for wrappers would be nice as well) Convincing the maintainers
that it is needed would be another story altogether. (I saw the thread
on wine-devel about the riched DLL's for Office)

As for the wscok wrapper: It seem that it might be completely based in
ws2_32 (which strangely enough gets loaded before wsock32 from loadll
output... I based this on strings output, which might not be the best
source, especially taking into account my lack of understanding of
interenal DLL structure) which might remove the need for a hack that
involves renaming the DLL

So in short - no it won't be fixed any time soon. You have to hack Wine/wrapper dll to make it do what you want. And if you don't have source - well you can hack it with hexedit