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?
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.
setupx.dll.so is a link do setupapi.dll.so, which emulates setupapi.dll and setupx.dll.
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.
===== Sylvain Petreolle spetreolle@users.sourceforge.net Fight Spam ! EuroCauce: http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
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+
On Sun, 02 Mar 2003 09:22:42 +0100, Eric Pouech eric.pouech@wanadoo.fr wrote:
that's may be something unrelated. could you describe this more precisely ?
Some days ago I sent a message concerning HTMLSetup
http://www.winehq.com/hypermail/wine-devel/2003/02/0728.html
Unfortunately I got no answer for that mail, but maybe it was not good enough phrased to raise some interest. :)
Gerhard W. Gruber wrote:
On Sun, 02 Mar 2003 09:22:42 +0100, Eric Pouech eric.pouech@wanadoo.fr wrote:
that's may be something unrelated. could you describe this more precisely ?
Some days ago I sent a message concerning HTMLSetup
http://www.winehq.com/hypermail/wine-devel/2003/02/0728.html
Unfortunately I got no answer for that mail, but maybe it was not good enough phrased to raise some interest. :)
well, it sounds like a bug in our setup-api implementation either try running with -debugmsg +setupapi to see what gives, or try running with native setupapi/setupx DLLs
HTH
A+
-
Eric Pouech -
Gerhard W. Gruber -
Sylvain Petreolle