Opened 14 years ago

Closed 13 years ago

Last modified 13 months 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 14 years ago.
experimental patch
9x-vs-NT-proper.diff (818 bytes ) - added by SF/andrej4000 14 years ago.
tested and working

Download all attachments as: .zip

Change History (10)

by SF/andrej4000, 14 years ago

Attachment: 9x-vs-NT.diff added

experimental patch

comment:1 by SF/andrej4000, 14 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, 14 years ago

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

tested and working

comment:2 by SF/andrej4000, 14 years ago

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

comment:3 by fingolfin, 14 years ago

I am not a windows developer but let me make some

* 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

* 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
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

See also tracker item #743288.

comment:4 by SF/andrej4000, 14 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
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, 13 years ago

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

comment:6 by Kirben, 13 years ago

Owner: set to Kirben
Resolution: outdated
Status: newclosed

comment:7 by Kirben, 13 years ago

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

comment:8 by digitall, 13 months ago

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