On Wed, Mar 01, 2000 at 06:24:55PM -0800, Alexandre Julliard wrote:
> Ah OK, I missed the difference between GetComputerName and
> GetComputerNameEx. The latter should of course use get/sethostname
> when accessing the DNS name, but for GetComputerName I agree we can
> probably store it once and for all.
>
> Still no reason to have a -init option, we can simply set the registry
> value from gethostname() if it didn't exist already.
So you mean setting it in a config script ?
Yes, that is possible, but I don't know whether we want to do so.
The problem is that in Wine, you have a well-defined and fixed API to
access the registry to set up any initial values needed.
But in a config script you depend on the registry file format.
If that changes, everything is broken and the script has to be rewritten.
So an alternative proposal by me would be to introduce a WINECONF.DLL
that does just that by means of -init.
And a DLL is less likely to be missed by package distributors than a
config script.
Oh, and BTW, some other registry keys to be installed based on Windows= and
System= entries in wine.conf are at
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup]
, such as
"WinBootDir"="C:\WINDOWS"
"WinDir"="C:\WINDOWS"
"ICMPath"="C:\WINDOWS\SYSTEM\COLOR"
So what should we choose ?
Wine builtin WINECONF.DLL or config script ?
With WINECONF, you could simply do wine -init if you want to reinit stuff.
You don't have to search where that extra script was...
And WINECONF would have the advantage that it's inside Wine, so it has
access to all information structures that it might need at some time.
Well, of course WINECONF isn't supposed to do *all* environment setup;
it should just be handy for the things that can be accomplished
in a better way by it than a script and that one might possibly want to
reinit by using -init.
Oh, and another one:
I'd like to write a program to create the DLL stubs containing VERSION_INFO.
Should this go into tools/build.c or be a separate program ?
I guess build.c is better, as you already have access to .spec files there,
which may be needed.
build.c already does the hard DLL stuff, so maybe just enhance it ?
So my proposal would be:
1. configure, make (build DLL stubs by means of build.c ?)
2. wineinstall (create wine.conf and install DLL stubs and other things)
\-> wine -init
This is a good check for the validity of wine.conf.
If the check failed, just tell the user to fix it
and to rerun wine -init, then exit.
And of course set up the registry values there.
And .INI files should be set there, too.
Hmm, or maybe we should have two separate parameters, -setup and -fixsetup ?
-setup would be responsible for setup, including dialog boxes asking the
user this and that, and -fixsetup would just fix the setup without any
user interaction ?
Andreas Mohr
