DLL Mapping in wine?
eric.pouech at wanadoo.fr
Sun Mar 2 02:22:42 CST 2003
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
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 ?
More information about the wine-devel