Re: Loadorder should check library name, not path

[Alexandre Julliard]

Uwe Bonnes  writes:
> at present, wine e.g. crashes if it finds user32.dll in the same directory
> as the executable. To keep wine from using this DLL, the dos-path to that
> dll has to be given explicit to the "-dll" argument, like
> wine h:/tmp/programm.exe --dll h:\tmp\user32.dll=b
> (e.g. with a user32.dll in h:/tmp/)
>
> I don't think we need that high granularity to select between builtin and
> native dlls.

Yes, there are cases where this is needed. Do you really have an app
that comes with its own user32.dll?  I don't see how this can work
under Windows either.

Loadorder should check library name, not path

[Uwe Bonnes]

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

Alexandre> Uwe Bonnes  writes:
    >> at present, wine e.g. crashes if it finds user32.dll in the same
    >> directory as the executable. To keep wine from using this DLL, the
    >> dos-path to that dll has to be given explicit to the "-dll" argument,
    >> like wine h:/tmp/programm.exe --dll h:\tmp\user32.dll=b (e.g. with
    >> a user32.dll in h:/tmp/)
    >> 
    >> I don't think we need that high granularity to select between builtin
    >> and native dlls.

Alexandre> Yes, there are cases where this is needed. Do you really have
    Alexandre> an app that comes with its own user32.dll?  I don't see how
    Alexandre> this can work under Windows either.

There are two cases:
- <windows/system> is populated with some executables. Calling them directly
  causes immediate crash
- for testing, I had comctl32.dll in the directory where the control-spy
  applications are. I took me some time to find out why even --dll
  comctr32=b still resulted in the use of native comctr32.

In both cases wine violates the "principle of least surprise" in my eyes.

Bye

Loadorder should check library name, not path

[Alexandre Julliard]

Uwe Bonnes  writes:
> There are two cases:
> - <windows/system> is populated with some executables. Calling them directly
> causes immediate crash

Only if windows/system is not configured as system directory. I don't
see why you'd want to do that.
> - for testing, I had comctl32.dll in the directory where the control-spy
> applications are. I took me some time to find out why even --dll
> comctr32=b still resulted in the use of native comctr32.
>
> In both cases wine violates the "principle of least surprise" in my eyes.

I agree it's a bit confusing; I've been making some changes to allow
using wildcards in there so that it's a bit easier to configure. I'm
open to other suggestions, but I don't think disabling the
functionality is the way to go.

Loadorder should check library name, not path

[Uwe Bonnes]

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

Alexandre> Uwe Bonnes  writes:
    >> There are two cases: - <windows/system> is populated with some
    >> executables. Calling them directly causes immediate crash

Alexandre> Only if windows/system is not configured as system
    Alexandre> directory. I don't see why you'd want to do that.

Several possibilities:
- several versions of winxx are available. You are trying to run one
executable in the context of another system
- you have an empty <windows/system> directory and want to run application
from the <windows/system> directory of the winxx available on your system.

At least me stumbled in some situations on that problem with native dlls
loaded while I configured/requested builtins.

Bye

Loadorder should check library name, not path

[Alexandre Julliard]

Uwe Bonnes  writes:
> Several possibilities:
> - several versions of winxx are available. You are trying to run one
>
> executable in the context of another system
> - you have an empty <windows/system> directory and want to run application
>
> from the <windows/system> directory of the winxx available on your system.

Note this would most likely crash and burn under Windows too. It's not
a common case at all, and you really need to know what you are doing
to make this work. And if you know enough to do it, adding explicit
paths in the loadorder config shouldn't be a big problem for
you. Sure, if we can make it easier we should (and I believe the
wildcards should help), but we should not sacrifice functionality for
such exotic cases.

Loadorder should check library name, not path

[Uwe Bonnes]

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

Alexandre> Uwe Bonnes  writes:
    >> Several possibilities: - several versions of winxx are available. You
    >> are trying to run one executable in the context of another system -
    >> you have an empty <windows/system> directory and want to run
    >> application from the <windows/system> directory of the winxx
    >> available on your system.

Alexandre> Note this would most likely crash and burn under Windows
    Alexandre> too. It's not a common case at all, and you really need to
    Alexandre> know what you are doing to make this work. And if you know
    Alexandre> enough to do it, adding explicit paths in the loadorder
    Alexandre> config shouldn't be a big problem for you. Sure, if we can
    Alexandre> make it easier we should (and I believe the wildcards should
    Alexandre> help), but we should not sacrifice functionality for such
    Alexandre> exotic cases.

Only for my understanding: Can you give (an) example(s) where the present
behaviour is usefull against the non-granulat approach.

In my win98se system directory are about 98 executables. I think only a few
are proposed to crash run on another system.

But I am more concered about the case where e.g. a comctl32 is in the
starting directory and you want to run the builtin dll...

Anyway, something like ' --dll "*/comctr32=b" ' that would defeat _any_
native comctl32 from loading is good too.

Bye

Loadorder should check library name, not path

[Alexandre Julliard]

Uwe Bonnes  writes:
> Only for my understanding: Can you give (an) example(s) where the present
> behaviour is usefull against the non-granulat approach.

There are cases where applications come with their own replacements
for system dlls, for one reason or another. This happens a lot with
installers for instance, and it's something we need to be able to
support, because if the Windows system dll doesn't work for the app
our builtin probably won't work either. In theory an app could even
come with a dll named comctl32 that has nothing to do with common
controls at all...
> Anyway, something like ' --dll "*/comctr32=b" ' that would defeat _any_
> native comctl32 from loading is good too.

That's basically what my patch will do.