Starting application from a directory with some kernel32.dll

[Uwe Bonnes]

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

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 
> To: [e-mail]
> 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                [e-mail]
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. [phone] -------- Fax. [phone] ----------

[Alexandre Julliard]

Uwe Bonnes  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.

[Uwe Bonnes]

> > > > > "Alexandre" == Alexandre Julliard  writes:

Alexandre> Uwe Bonnes  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

[Alexandre Julliard]

Uwe Bonnes  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.