RFC: more Windows-NT like user directories?

[Juan Lang]

Folks, I'm still working on the shell path functions,
and I was thinking of changing the directory layout
for the shell directories (desktop, start menu, my
documents and whatnot) from the Windows 95-ish way to
the NT-ish way.  That is, rather than being children
of c:\windows, they'd generally be children of
c:\documents and settings<username>.

Any complaints?
--Juan

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

[Mike Hearn]

Juan Lang wrote:
> Folks, I'm still working on the shell path functions,
> and I was thinking of changing the directory layout
> for the shell directories (desktop, start menu, my
> documents and whatnot) from the Windows 95-ish way to
> the NT-ish way.  That is, rather than being children
> of c:\windows, they'd generally be children of
> c:\documents and settings<username>.
>
> Any complaints?

Why the change? Being more NT-ish isn't necessarily a good thing.

Currently Wine ignores multi-user stuff and delegates it to the host 
system. As your fake windows drive is probably already in $HOME having a 
separate Documents and Settings directory seems superflous.

I suppose some admins may want a shared fake windows drive but separate 
menus/icons (seems a bit odd seeing as the registry wouldn't be shared), 
but if so we probably need to think that through properly 
(ownership/permissions/etc).

thanks -mike

[Juan Lang]

--- Mike Hearn  wrote:
> Why the change? Being more NT-ish isn't necessarily
> a good thing.

More consistency, mainly.  Sometimes things go to
c:\windows\profiles\Administrator (regardless of
username), and othertimes they go to
c:\windows\something or other.

That, plus I only have an NT-ish system around to test
with at the moment :)
> Currently Wine ignores multi-user stuff and
> delegates it to the host 
> system. As your fake windows drive is probably
> already in $HOME having a 
> separate Documents and Settings directory seems
> superflous.

It does, but so's the current code, which writes to
~/.wine/drive_c/My Documents or some such place.

When I run wineprefixcreate I only get two drives, c:
and z: (which maps to /).  Should there be a $HOME
drive mapping, and should I point the "my documents"
directory to that instead?  I don't think populating
your home directory with a "Temporary Internet Files"
and a "Templates" directory is actually a good
thing--these should probably be hidden in the fake
drive c:.

--Juan

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

[Mike Hearn]

> When I run wineprefixcreate I only get two drives, c:
> and z: (which maps to /).  Should there be a $HOME
> drive mapping, and should I point the "my documents"
> directory to that instead?

Yes, I think that'd be a good idea.

In theory My Documents can be controlled by the registry. In practice I 
think quite a few apps hard code it. So maybe we could make My Documents 
a symlink to Y: or whatever we use as the home drive.

Currently symlinks are disabled by default in case of loops. I think we 
could have some smarter logic to detect that case though, then we could 
make sure every app which used My Documents was really looking at the 
UNIX home directory.

wineprefixcreate needs a fair bit of love actually. Right now its drive 
detection code is rather poor, and there are various packager-specific 
patches floating around to improve it. These should be moved upstream.

[Vincent Béron]

Le lun 20/09/2004 à 11:33, Mike Hearn a écrit :
> > When I run wineprefixcreate I only get two drives, c:
> > and z: (which maps to /).  Should there be a $HOME
> > drive mapping, and should I point the "my documents"
> > directory to that instead?
>
> Yes, I think that'd be a good idea.
>
> In theory My Documents can be controlled by the registry. In practice I 
> think quite a few apps hard code it. So maybe we could make My Documents 
> a symlink to Y: or whatever we use as the home drive.
>
> Currently symlinks are disabled by default in case of loops. I think we 
> could have some smarter logic to detect that case though, then we could 
> make sure every app which used My Documents was really looking at the 
> UNIX home directory.

What about a hard link then? (~/My Documents == $fake_c/My Documents)
Of course it won't work if $fake_c is on another partition, and spaces
in filename in ~/ are not something I personnally like, but it'd get the
correct functionnality most of the time. Bonus is ~/My Documents would
survive the removal of the $fake_c (but its contents wouldn't, sadly, so
I'm not sure about the last point :P).

Vincent

[Juan Lang]

--- Mike Hearn  wrote:
> In theory My Documents can be controlled by the
> registry. In practice I 
> think quite a few apps hard code it.

Do you think so?  I'd be a little surprised, since
it's c:\My Documents on Win9x-ish systems (in single
user mode) and c:\Documents and Settings<username>\My
Documents on Win2k/XP.  (That, plus it's a localized
name.)  On old apps that assume Win95 perhaps.

--Juan

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

[Kevin Koltzau]

On Monday 20 September 2004 11:56 am, Juan Lang wrote:
> --- Mike Hearn  wrote:
> > In theory My Documents can be controlled by the
> > registry. In practice I 
> > think quite a few apps hard code it.
>
> Do you think so?  I'd be a little surprised, since
> it's c:\My Documents on Win9x-ish systems (in single
> user mode) and c:\Documents and Settings<username>\My
> Documents on Win2k/XP.  (That, plus it's a localized
> name.)  On old apps that assume Win95 perhaps.

I would be quite surprised by this as well, as its somewhat common
practice for companies to point "My Documents" to a network share
for backup purposes, including with Win95/98

[Mike Hearn]

> I would be quite surprised by this as well, as its somewhat common
> practice for companies to point "My Documents" to a network share
> for backup purposes, including with Win95/98

Well, I know it's a problem I've encountered before, and it's also a 
common issue on localized Windows systems. You get c:\My Documents in 
both French and English, for instance.

[Alexandre Julliard]

Mike Hearn  writes:
> wineprefixcreate needs a fair bit of love actually. Right now its
> drive detection code is rather poor, and there are various
> packager-specific patches floating around to improve it. These should
> be moved upstream.

Drive detection should be done in winecfg (in a way that can be
invoked from wineprefixcreate), since people may want to update parts
of their drive config without rebuilding the whole .wine directory.

[Mike Hearn]

> Drive detection should be done in winecfg (in a way that can be
> invoked from wineprefixcreate), since people may want to update parts
> of their drive config without rebuilding the whole .wine directory.

Hmm. I noticed that wineprefixcreate has an --update option. I assumed 
that meant it would rescan the system and non-destructively update the 
links.

Thinking about it, I suppose we need getmntent which is a bit tricky to 
duplicate in shell. So it has to be written in C. Ugh.

By the way, I was working on winecfg some more last night. I'm still not 
sure what the exact plan is for config migration.

What'd be best from my point of view (winecfg) is to move the config 
heirarchy from eg

HKLM/Software/Wine/Wine

to

HKLM/Software/Wine/Config

or somewhere else, anywhere really, the key is keeping the current 
structure and layout. That also has the advantage that users are 
familiar with the current layout so it's less of a shock when the config 
file disappears, there's no need to consult a big list to find out where 
a setting went.

Currently there is code like this:

set(keypath("x11drv"), "Desktop", "640x480")

which will do the right thing w.r.t global settings/appdefaults. This is 
convenient for people adding new settings to the program as well as 
keeping the code fairly clean (apply/cancel is implemented as an overlay 
on top of the registry and it works well).

This becomes somewhat less convenient if things are scattered around 
everywhere, especially if appdefaults no longer mirror the global 
settings heirarchy.

So is the plan to copy the config branch to a different branch, or to do 
each setting individually? If the latter, why?

thanks -mike

[Alexandre Julliard]

Mike Hearn  writes:
> Hmm. I noticed that wineprefixcreate has an --update option. I assumed
> that meant it would rescan the system and non-destructively update the
> links.

No, it can't do that, you have no way of knowing which links were
autodetected and need to be updated, and which ones have been
explicitly set by the user and must not be touched.
> This becomes somewhat less convenient if things are scattered around
> everywhere, especially if appdefaults no longer mirror the global
> settings heirarchy.
>
> So is the plan to copy the config branch to a different branch, or to
> do each setting individually? If the latter, why?

Most things should be moved straight to HKLM/Software/Wine; there are
some exceptions for things that we want to take the opportunity to
fix, or for things that will no longer be part of the config. But I
don't think any of these are handled by winecfg at the moment; things
like DllOverrides and x11drv will be moved unchanged to
HKLM/Software/Wine.

[Mike Hearn]

> No, it can't do that, you have no way of knowing which links were
> autodetected and need to be updated, and which ones have been
> explicitly set by the user and must not be touched.

Hmm. We could have a magic marker file ~/.wine/dosdevices/.auto.d: for 
instance, but that'd be a bit ugly.

In future it'd be nice to notice when the fstab has changed and rerun 
the auto-detect procedure automatically, so the user can plug in a USB 
key, have HAL set things up automatically, then run their Wine program 
and have it appear in the file dialogs.

To do that, we'd need to be able to non-destructively update the drive 
links.
> Most things should be moved straight to HKLM/Software/Wine; there are
> some exceptions for things that we want to take the opportunity to
> fix, or for things that will no longer be part of the config. But I
> don't think any of these are handled by winecfg at the moment; things
> like DllOverrides and x11drv will be moved unchanged to
> HKLM/Software/Wine.

OK, that's great, exactly what I wanted to hear :)

thanks -mike

[Alexandre Julliard]

Mike Hearn  writes:
> > Most things should be moved straight to HKLM/Software/Wine; there are
> > some exceptions for things that we want to take the opportunity to
> > fix, or for things that will no longer be part of the config. But I
> > don't think any of these are handled by winecfg at the moment; things
> > like DllOverrides and x11drv will be moved unchanged to
> > HKLM/Software/Wine.
>
> OK, that's great, exactly what I wanted to hear :)

One thing to keep in mind is that at some point we'll probably want to
put the user-modified settings in HKCU instead of HKLM, so that the
HKLM ones can be maintained automatically by wine.inf and friends.
That will probably also require winecfg to somehow take into account
the HKLM defaults and only record modified settings in HKCU, or
something like that. But we can certainly live with everything in HKLM
for now.

[Mike Hearn]

> One thing to keep in mind is that at some point we'll probably want to
> put the user-modified settings in HKCU instead of HKLM, so that the
> HKLM ones can be maintained automatically by wine.inf and friends.
> That will probably also require winecfg to somehow take into account
> the HKLM defaults and only record modified settings in HKCU, or
> something like that. But we can certainly live with everything in HKLM
> for now.

That should be pretty easy to implement. Right now I'm attacking the 
drive configuration and I go back to university on a week Saturday so no 
promises that it'll actually be done, but it should be trivial for 
somebody else to do with the new code.

[wine] RFC: more Windows-NT like user directories?

[David Lee Lambert]

On Mon, Sep 20, 2004 at 12:32:19AM -0700, Juan Lang wrote:
> Folks, I'm still working on the shell path functions,
> and I was thinking of changing the directory layout
> for the shell directories (desktop, start menu, my
> documents and whatnot) from the Windows 95-ish way to
> the NT-ish way.  That is, rather than being children
> of c:\windows, they'd generally be children of
> c:\documents and settings<username>.

Please remember that under Windows 95 with multiple users or Windows NT 4, per-user 
settings are stored under C:\WINDOWS\Profiles<username> or 
C:\WINNT\Profiles<username> (if I remember rightly).  The actual paths are stored 
in the Registry;  or are you just thinking about changing the default locations for 
new installations?

Either layout is fine for testing-only installations, but in a production
environment I would probably point the "Desktop" to $HOME/Desktop (shared with KDE)
and "My Documents" to $HOME/ .  The have been regular questions on the users list
asking how to do things like this.

[wine] RFC: more Windows-NT like user directories?

[Juan Lang]

--- David Lee Lambert  wrote:
> Please remember that under Windows 95 with multiple
> users or Windows NT 4, per-user 
> settings are stored under
> C:\WINDOWS\Profiles<username> or 
> C:\WINNT\Profiles<username> (if I remember
> rightly).  The actual paths are stored 
> in the Registry;  or are you just thinking about
> changing the default locations for 
> new installations?

Yes, I know.  The current code is a bit off: it uses
c:\windows\profiles\Administrator as your profile
directory, and generally c:\windows<something> to
actually store things.  I'm talking about the default
registry values for new installations.

--Juan

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

[Dimitrie O. Paun]

On Mon, Sep 20, 2004 at 12:32:19AM -0700, Juan Lang wrote:
> Folks, I'm still working on the shell path functions,
> and I was thinking of changing the directory layout
> for the shell directories (desktop, start menu, my
> documents and whatnot) from the Windows 95-ish way to
> the NT-ish way.  That is, rather than being children
> of c:\windows, they'd generally be children of
> c:\documents and settings<username>.
>
> Any complaints?

Hmm, shouldn't they be children of /home/<username> instead?

[Juan Lang]

--- "Dimitrie O. Paun"  wrote:
> Hmm, shouldn't they be children of /home/<username>
> instead?

Hmm, that's not a bad idea.  I probably won't
implement it though, at least not this go-round :)

--Juan

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail