Andreas Mohr <[EMAIL PROTECTED]> writes:
> And my main argument is that there will still be many users left
> with broken or "half-upgraded" setups that don't benefit from an
> improved setup as they "just forgot" to execute the setup script after
> the fifth upgrade.
> That can't happen when that functionality is builtin.
Oh please... should we also include the whole source in the Wine
executable so that we can automatically recompile libwine.so in case
the user deleted it?
This is a packaging issue; we need to have proper install scripts, and
users who don't know what they are doing should use an rpm or debian
package that will do everything for them. This stuff does not belong
in the Wine executable.
> And about the builtin version info:
> Should we either store this
> - in these DLLs you propose(d)
> or
> - in the builtin (or separated in the future) DLLs
> and add functionality to the Ver*() functions to read that out ?
>
> Hmm, I used to think that external DLLs are problematic as they can only
> have one VS_VERSION_INFO, not one for each windows version to be emulated.
> But of course we can add as many VS_VERSION_INFO as we want and enhance
> Ver*() to switch between them according to the current winver.
The problem is that the dummy dlls will only exist if we do not have
the real Windows dlls; so if we want to report different versions
depending on the winver flag it needs to be stored in the .so library.
OTOH if we do have the Windows dlls the Ver*() functions will get the
version info from there, unless we change them to take into account
the builtin/native switch.
--
Alexandre Julliard
[EMAIL PROTECTED]
