RFC: more Windows-NT like user directories?
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
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
--- Mike Hearn <m.hearn(a)signal.QinetiQ.com> 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
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.
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
--- Mike Hearn <m.hearn(a)signal.QinetiQ.com> 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
On Monday 20 September 2004 11:56 am, Juan Lang wrote:
--- Mike Hearn <m.hearn(a)signal.QinetiQ.com> 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
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.
Mike Hearn <m.hearn(a)signal.qinetiq.com> 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. -- Alexandre Julliard julliard(a)winehq.org
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
Mike Hearn <m.hearn(a)signal.QinetiQ.com> 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. -- Alexandre Julliard julliard(a)winehq.org
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
Mike Hearn <m.hearn(a)signal.QinetiQ.com> 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. -- Alexandre Julliard julliard(a)winehq.org
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.
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. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
--- David Lee Lambert <lamber45(a)cse.msu.edu> 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
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? -- Dimi.
--- "Dimitrie O. Paun" <dpaun(a)rogers.com> 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
participants (7)
-
Alexandre Julliard -
David Lee Lambert -
Dimitrie O. Paun -
Juan Lang -
Kevin Koltzau -
Mike Hearn -
Vincent Béron