On Wed, Mar 01, 2000 at 02:55:36PM -0800, Alexandre Julliard wrote:
> 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.
Well, OK, I guess you finally managed it :)
> > 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.
I guess that's rather a non-issue.
Original Windows DLLs will go away at some point in time or another anyway,
and that'll make it acceptable to live with single-versioned VERSION_INFO:s.
(how often do they get queried anyway ?)
And of course we should really make sure that we *have* these DLLs installed.
We should have one standard ("authoritative") install script
(I guess that's wineinstall ?) that is called to update the config and call
wine -init (if we implemented it).
I'm afraid we might not do this properly, so I'm trying to force us into
doing that now and in a correct way ;)
But what about -init ?
Should I add such a parameter ?
I'd like to implement e.g. (G/S)etComputerNameA properly and add a config
init function to Wine.
Andreas Mohr
