#8526 closed patch (outdated)
Patch for relocating scummvm.ini on NT systems
| Reported by: | SF/andrej4000 | Owned by: | Kirben |
|---|---|---|---|
| Priority: | normal | Component: | Port: Win32 |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
This is just a sketch and I can't link scummvm.exe to test it, but I think it should be enough to respect the missing rights of non-admin users of NT systems.
Ticket imported from: #1476081. Ticket imported from: patches/631.
Attachments (2)
Change History (10)
by , 18 years ago
| Attachment: | 9x-vs-NT.diff added |
|---|
comment:1 by , 18 years ago
OK, now I could test the code and correct it a little bit.
It works properly on my WinXP Home OS (German).
comment:2 by , 18 years ago
| Summary: | Sketch for relocating scummvm.ini on NT systems → Patch for relocating scummvm.ini on NT systems |
|---|
comment:3 by , 18 years ago
I am not a windows developer but let me make some remarks:
* The patch contains mixed line endings (both unix and windows ones)
* GetVersionEx is used incorrectly. According to MSDN, at least, they should know :-). See <http://msdn.microsoft.com/library/default.asp?url =/library/en-us/sysinfo/base/getversionex.asp> and <http://msdn.microsoft.com/library/default.asp?url =/library/en-us/sysinfo/base/ getting_the_system_version.asp>
* Is it really a good idea to query "USERPROFILE" without any further checks? I.e. is it 100% guranteed that this env var always exists and points to a suitable directory?
* According to <http://msdn.microsoft.com/library/default.asp?url =/library/en-us/sysinfo/base/getwindowsdirectory. asp>, we should use HOMEPATH anyway?
* And anyway, should we really store in USERPROFILE/HOMEPATH directly, as opposed to a subdirectory called ScummVM (or something like that) ?
While it's nice to see some work finally being done on this, this is still a very delicate issue. It's not fully clear what the "best" solution is.
Also, existing users would rightgully be quite annoyed, to say the least, if we suddenly ignored their config file in the windows directory. We should provide some kind of migration path, should we decide to implement a patch similar to the one attached here. I.e. at the very least display a warning: If no config file is present in the "new" location, but we see one in the windows dir, ask the user, tell the user about it, and ask them to move the file (or even offer to move/copy the file).
See also tracker item #743288.
comment:4 by , 18 years ago
* mixed line endings were made by my diff-generator (TortoiseSVN), so I didn't look at it.
* OK, I forgot to set the size of the struct, but apart from it the identification of the system (if it's NT-based or not) should work. (It works at my home with WinXP Home and at my work with Win2k Pro)
* the "USERPROFILE" is always generated automatically, while "HOMEPATH", "HOMEDRIVE", "HOMESHARE" and "APPDATA" can be set directly in the user's registry.
* a user with admin rights can of course mess with all system var, even with "USERPROFILE", but that's the problem of the user, not of ScummVM
* "HOMEDRIVE"+"HOMEPATH" and "USERPROFILE" are per default identical, but can be set to different drives and directories, the difference is, that the "USERPROFILE" always point to the profile itself (the profile is e.g. saved to a server in a domain environment), "HOMEDRIVE" + "HOMEPATH" can be anywhere in the system or on a mapped network drive.
* I just wrote a simple skript without creating the subfolder "ScummVM". If you look inside the first draft I relied on the existence of this subfolder, creating the scummvm.ini failed, if the subfolder didn't exist, so I just went the simplier way and removed the subfolder from the path, to make faster a working example. I'm pro subfolder. :-)
One possibilty is to move the scummvm.ini from the windir to the new dir if we detect an existing ini. (You mentioned it)
The other possibility is that we default on creating the ini inside our dir, but if we find an ini inside the windir, that is interpreted instead of the on on our dir.
comment:6 by , 18 years ago
| Owner: | set to |
|---|---|
| Resolution: | → outdated |
| Status: | new → closed |
comment:7 by , 18 years ago
Closing, due to more developed patch been submitted, using this method, see patch item #1511993.
comment:8 by , 5 years ago
| Component: | → Port: Win32 |
|---|
experimental patch