Juergen Schmied wrote:
> > > If you want to do system-wide configuration you do it in HKLM (or in
> > > /etc on UNIX).
> User values in HKCU are never system wide. Period.
> Only default values in HKU/.Default are copyed at the time of user creation.
> Leter changes in HCU/.Default are not changing HKCU
>
>
> > So? The global wine.userreg (with .Default) will reside in /etc, right?
> A user.reg is per definition never system wide.
>
Correct, although the .Default users files should probably reside in /usr/share/wine
since
it will need to be copied when creating a new user.
>
> > > You can write a shell script to export HKEY_USERS\.Default and then sed it to
> > > HKEY_USERS\username and then import it.
> Yes, this is OK.
>
Not really, it's kind of hackish, but it was the first idea that popped into my head.
>
> > No plans. That has "user-unfriendly" spelled all over it. It's okay if a
> > system administrator has to do some work to make a wine installation work
> > for everyone, but there should not be extra setup work per user!
> At the moment wine is single user so the wine installation has to do it.
> This might change at some point. Then we would need a adduser in any case.
>
I think you are right here too. This is how Windows is supposed to work. If you
create
an account then there are certain things that need to be done before you can use it.
Hell, that is also how UNIX works, you need to copy /etc/skel to the users homedir and
do
some other things to add the user.
>
> > > Also, you shouldn't absolutely NEED a setting in HKEY_CURRENT_USER to
> > > run a program.
> Yes. Programs expecting this are broken. Exception: shell/explorer specific setting
> like the ShellFolders we are talking about. This values are created on first user
>logon
> and its save to expect the keys on place.
>
And actually, they are remade if you delete them when explorer restarts (killed
explorer,
and when it came back they had been recreated).
>
> > But you do, as has been shown time and time again. Installers need Shell
> > Folders and probably other stuff that we figure out later and have to add
> > to winedefault.reg... wouldn't it be nice if all system administrators
> > could retro-add the new keys we figured out we need, without going through
> > every single user's account?
> No, my keys are my keys. The admin should change HKLM and not touch HKCU
> like I would not like the admin to change files in ~myuser/. He can provide a initial
> set of settings but he has not to touch my settings later. This is the way HKCU
> works. I think this is completely UNIX compatible.
>
Yes, let's say desktop themes were implemented in Wine. I'd be pissed if I had been
using
the default them and thus never changed my settings and all of a sudden the admin
changes
the default and my theme is different. Of course if I had defined my own theme then it
wouldn't have effected me, but I shouldn't have to do that if I don't want to. The
default theme should be copied once at user creation and should then never change.
If an admin REALLY wants to change the settings for every user (for example, configure
the
outlook express for each user to use the correct server and all) then what really
needs to
be done is to use the windows mechanisms for this instead of mucking around with the
registry.
Okay, let's say you have two user accounts on a real WinNT machine, one Administrator
and
one normal.
You install Outlook express.
The first time you log into any account after installing OE, you'll notice that Windows
Setup is "configuring personalized settings for the following components".
Until a user logs into their account, they won't have settings for that component.
Now, let's say you uninstall OE. The settings actually remain until your next login at
which point you'll notice that it removes your personalized settings for the component.
>
> If the user hasn't changed its directory locations there are no keys in
> HKCU.
>
> The current problems are:
> - There are no default paths in HKLM created and SHGetSpecialFolderLocation is
> not supposed to create keys there.
> - SHGetSpecialFolderLocation does not read HKLM if no keys in HKCU are found.
>
> To fix this:
> - create default keys in HKLM
> --> WE NEED A BETTER WINE INSTALLER !!! - not every time the windows
> directory is "c:\windows" like in winedefault.reg. the current hard coded paths
> in winedefault.reg are likely a source for many problems.
> - implement right SHGetSpecialFolderLocation to read HKLM (yes I do it!)
>
> and everything would be fine.
Yes, I would suggest using H:\.wine for profile data instead of C:\WINDOWS. This is
completely compatible with both UNIX philosophy and Windows NT philosophy. In Windows
NT
users all have their own favorites/start menu/desktop/etc. There are also common start
menu entries and desktop entries which are located in a system wide folder (i would
suggest /usr/share/wine/***)
I would also suggest mappying /usr/share/wine to a drive letter (I'll use X for now).
You
could then set up X:\WINNT and X:\Program Files and other stuff. For some reason
people
get the idea that Windows should always be on the C: drive. It's very common for NT
to be
on another drive, so we could use X:\ which would leave the other drive letters free
for
possibly mounting the real C: drive of the computer to access the files from a real
Win9x
install.
Actually, what we really need is a genuine package of Wine. I think marcus had
mentioned
working on RPMs, why not contribute the .spec directly into the wine CVS source tree so
that it can evolve with wine. I would also suggest making tools/wineinstall more
modular
so that the .spec can run parts of it during the %build and %install sections, and
other
parts during the %pre or %post sections.
I am not very familiar with debian packages, but I would hope that doing this would
also
benefit someone trying to make a .deb.
-Dave
