Opened 15 years ago

Closed 14 years ago

Last modified 2 years ago

#8526 closed patch (outdated)

Patch for relocating scummvm.ini on NT systems

Reported by: SF/andrej4000 Owned by: Kirben
Priority: normal Component: Port: Win32
Keywords: Cc:


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)

9x-vs-NT.diff (864 bytes ) - added by SF/andrej4000 15 years ago.
experimental patch
9x-vs-NT-proper.diff (818 bytes ) - added by SF/andrej4000 15 years ago.
tested and working

Download all attachments as: .zip

Change History (10)

by SF/andrej4000, 15 years ago

Attachment: 9x-vs-NT.diff added

experimental patch

comment:1 by SF/andrej4000, 15 years ago

OK, now I could test the code and correct it a little bit.

It works properly on my WinXP Home OS (German).

by SF/andrej4000, 15 years ago

Attachment: 9x-vs-NT-proper.diff added

tested and working

comment:2 by SF/andrej4000, 15 years ago

Summary: Sketch for relocating scummvm.ini on NT systemsPatch for relocating scummvm.ini on NT systems

comment:3 by fingolfin, 15 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 < =/library/en-us/sysinfo/base/getversionex.asp> and < =/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 < =/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 SF/andrej4000, 15 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:5 by fingolfin, 14 years ago

Ref: See also patch #1511993 and feature request #743288.

comment:6 by Kirben, 14 years ago

Owner: set to Kirben
Resolution: outdated
Status: newclosed

comment:7 by Kirben, 14 years ago

Closing, due to more developed patch been submitted, using this method, see patch item #1511993.

comment:8 by digitall, 2 years ago

Component: Port: Win32
Note: See TracTickets for help on using tickets.