DLL Mapping in wine?

[Eric Pouech]

Gerhard W. Gruber wrote:
> When I use winedbg I noticed that it lists all the DLLs and so files that are
> loaded. In case of DLLs that are already present in wine the original DLL is
> requested and the appropriate so file is loaded. Where is that mapping done
> for wine to determine which so to load?
we use two different schemes:
- the wineserver sends a specific event to the debugger each time a 
debugged process loads a (PE) DLL. The debugger, when processing this 
event, gets a handle to the file which was used to load the DLL, and the 
base address in debugged process memory where the new DLL got loaded. We 
get debug information from these two pieces (depending on the debug format)
- the debugger also sets a breakpoint in debugged process in the ELF 
loader. This breakpoint gets triggered each time a new ELF (.so) file 
gets loaded.

The debugger then synchronizes those two types of information to provide 
the full list of loaded modules. Remember that builtin DLLs in wine are 
created as ELF (.so) files, and may contain several DLLs.
using 'info share' in winedbg shows this relationship

> I noticed that there is a setupapi.dll.so but the program tries to load
> setupapi.dll and setupx.dll.so is loaded instead. Is this correct? I would
> have expected setupapi.dll.so to be loaded. Consequently the program gets an
> exception telling me that it has some wrong INF stuff.
that's may be something unrelated. could you describe this more precisely ?

A+

-- 
Eric Pouech