when shell32.dll is registered during wineprefixcreate, it puts a lot of paths based on Z:\ in HKLM/HKCU Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. This is due to resolving CIDL_PERSONAL to the DOS path corresponding to $HOME.
If people remove the Z: drive afterwards, this leads to a lot problems (One being that the Desktop shellfolder won't initialize any more, which breaks the complete shell namespace and thus the file dialogs).
Yeah, that is painful.
I'm proposing to add two more environment variables: %PERSONAL%, which would be expanded to the DOS path corresponding to $HOME if this exists, or to %USERPROFILE%\My Documents if not (with "My Documents" resource based, of course). And %DESKTOP%, which would be expanded to DOS_PATH_OF($HOME)\Desktop if existent and to %USERPROFILE%\Desktop, if not.
So the environment variable expansion would be based on shell32? Ouch. I don't think that'll fly.
I'm of the opinion that all this fancy CSIDL_PERSONAL mapping doesn't belong in shell32, even though I put it there. shell32 should default to creating paths that are part of the profiles directory if nothing else exists, since the shell won't work without them. But creating Linux-environment-friendly defaults should perhaps go in wineprefixcreate. I actually rather liked the idea of putting it in winecfg, and launching winecfg in a GUI-less mode from wineprefixcreate. The advantage is that the drive mappings and shell folder creation would be in the same app, and so would have some hope of staying consistent.
If a user breaks it through direct registry manipulation, his fault. If she breaks it through normal use of our tools, our fault.
--Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com