Starting application from a directory with some kernel32.dll
Hallo, when an application is run in a directory, where there is also a kernel32.dll, and this is _not_ the system directory, MODULE_GetLoadOrder doesn't strip the path and therefore crashes when native kernel32.dll is loaded. While the header of MODULE_GetLoadOrder talks about "any path is stripped", the function only strips the path for "16 bit modules or if the module resides in the system directory " Is this intended behaviour? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Wouldn't using a native kernel32.dll be a bad and a snowballs-chance-in-hell-of-working thing anyway? :) Regards, | It's always bad news in computing.. and beware | of anything claming to be good news - because | its probably a virus. - Salmon Days Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] On Mon, 8 Apr 2002, Uwe Bonnes wrote:
Date: Mon, 8 Apr 2002 16:18:23 +0200 From: Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> To: wine-devel(a)winehq.com Subject: Starting application from a directory with some kernel32.dll
Hallo,
when an application is run in a directory, where there is also a kernel32.dll, and this is _not_ the system directory, MODULE_GetLoadOrder doesn't strip the path and therefore crashes when native kernel32.dll is loaded.
While the header of MODULE_GetLoadOrder talks about "any path is stripped", the function only strips the path for "16 bit modules or if the module resides in the system directory "
Is this intended behaviour?
Bye
-- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
when an application is run in a directory, where there is also a kernel32.dll, and this is _not_ the system directory, MODULE_GetLoadOrder doesn't strip the path and therefore crashes when native kernel32.dll is loaded.
While the header of MODULE_GetLoadOrder talks about "any path is stripped", the function only strips the path for "16 bit modules or if the module resides in the system directory "
Is this intended behaviour?
Yes, there can be multiple versions of a 32-bit dll with the same name in different directories, and we have to be able to configure them separately. -- Alexandre Julliard julliard(a)winehq.com
"Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes:
Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> when an application is run in a directory, where there is also a >> kernel32.dll, and this is _not_ the system directory, >> MODULE_GetLoadOrder doesn't strip the path and therefore crashes when >> native kernel32.dll is loaded. >> >> While the header of MODULE_GetLoadOrder talks about "any path is >> stripped", the function only strips the path for "16 bit modules or >> if the module resides in the system directory " >> >> Is this intended behaviour? Alexandre> Yes, there can be multiple versions of a 32-bit dll with the Alexandre> same name in different directories, and we have to be able to Alexandre> configure them separately. But loading native kernel32 and friends will lead to a crash. Would you abject an explicit check for those? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
But loading native kernel32 and friends will lead to a crash. Would you abject an explicit check for those?
As long as it is configurable that would be acceptable. But you cannot simply hard-code kernel32 as builtin all the time, there may be cases where you want to load the native. And note that you can already specify a full path in the load order config so you could use that to solve the problem in your case. -- Alexandre Julliard julliard(a)winehq.com
participants (3)
-
Alexandre Julliard -
Uwe Bonnes -
winedev@admdev.com