Opened 16 years ago

Closed 13 years ago

Last modified 6 months ago

#7273 closed enhancement (fixed)

WIN: Look for config file in multiple places

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

Description

In the Windows version, it would make more sense to
have the default path for scummvm.ini to be in the
current directory rather than the system directory.
This makes it easier to make changes in scummvm.ini.

Ticket imported from: #743288. Ticket imported from: feature-requests/89.

Change History (44)

comment:1 Changed 16 years ago by SF/hibernatus

Why don't you simply make a shortcut to scummvm.ini?

comment:2 Changed 16 years ago by SF/itsr0y

I could create a shortcut, but it seems like common practice
to put all files belonging to a particular program in that
program's folder. By placing files in other places, it
makes it difficult to uninstall (I know it's not that
difficult, but it's still not as easy as just deleting the
program folder.) Also, by having it in the program's
folder, it makes it easier to use separate scummvm.ini files
for different versions of the program.

comment:3 Changed 16 years ago by SF/ender

Summary: WIN: Move scummvm.ini to current directoryWIN: Append current directory's config to the global config

comment:4 Changed 16 years ago by SF/ender

However I do not want this behavor.

ScummVM is designed to be as portable yet idiot-proof as
possible. Most programs either store their configuration in an
.ini file in the game data directory, in the Windows directory or
in the registry. The last we do not want to use for portability.

Our game data directory changes, and scummvm.exe can be
ran from anywhere. Thus we put the file in the Windows
directory with other .ini's. I don't see any reason that storing it
in CWD would be useful. (Why -would- you want to use
multiple config files for different versions of ScummVM?!?)

At some stage I would like to make it APPEND the
./scummvm.ini file to the current config, but we will still always
store the global configuration in a global location
(homedir, or on this platform the windows dir)

comment:5 Changed 16 years ago by SF/jamieson630

If the global scummvm.ini and ./scummvm.ini set a different
value to the same property in the same domain, which one
would take precedence?

Personally, I can't see modifying the global scummvm.ini
from ./scummvm.ini, but I *can* see using the ./scummvm.ini
settings if an appropriate domain is defined therein.
Conceptually it would just become one more step in the
prioritization of competing domains. For example, domains may
be applied in this order, effecting lowest to highest priority:

Global INI, [scummvm] domain
Local INI, [scummvm] domain
Global INI, [game-specific] domain
Local INI, [game-specific] domain
Command Line Options
GUI Launcher Options

As with command line options, settings from the local INI
should ONLY append/overwrite settings in the global INI if
the -w option is used, IMO.

comment:6 Changed 16 years ago by fingolfin

Owner: set to fingolfin

comment:7 Changed 15 years ago by SF/loki1985

at least having the OPTION to have .ini in current dir would
be useful, for example when using a XP pc with no rights for
writing to windir...

my indea of the perfect solution: if scummvm doesn't find
a .ini in CWD, allright, use %windir%.
but if there IS a scummvm.ini in CWD, it is there because ME
(the user) copied/created it in there. so i know what i want
and NOW scummvm should use ./scummvm.ini.
(that shouldn't be hard to implement).
that way it would be easy for newbies AND more powerful for
experts.

and merging different configs together isn't good!
in my eyes it should be a clear EITHER, OR!

it's just a suggestion.

comment:8 Changed 15 years ago by SF/ender

Current CVS (and thus 0.6.0) now allows specifying an alternate
configuration path on the commandline via the -c/path/to/file
(long version: --config=/path/to/file) option. Note this replaces the
global config and does NOT append to it, unlike the request in
this RFE.

The default still is, and will always be, to search the 'global
location' (~ on *nix, %windir% on Win32).

comment:9 Changed 15 years ago by SF/loki1985

thanx >:)

comment:10 Changed 15 years ago by SF/kaminari

Let's just forget about that .ini merging mess. Why not simply
make ScummVM default to windir (as it is now), *and* fall
back to progdir if it can't find scummvm.ini in windir? It would
make sense for everyone (at least for me).

On a personal note, I don't like the .ini file in windir, and I tell
you why. As 99% of the Windows users, I'm the sole user of
this computer. When I move my folders around (say, I want
to copy the ScummVM folder from one hard drive to another
because I need to reformat the drive or install a new one), I
don't want to waste my time scouring my old windir or my C:\
user directory for configuration files that would have been
better located in their respective progdir in the first place.

Just my two eurocents.

comment:11 Changed 15 years ago by SF/ender

See below. I've said it before and I'll say it again - NO!

comment:12 Changed 15 years ago by fingolfin

Ender, you said it before, but you didn't explain it before. Kaminari just
explained very nicely why he wants that feature. Personally, I don't care
too much about Windows, but the suggestion sounds reasonable. I am
sure you have your reasons, too, but what are they?

comment:13 Changed 15 years ago by SF/ender

I did explain it, it's the third comment on this bug. IMHO, It still
applies even with Kaminaris fallback concept. Not to mention that
I see no easy reason to decide whether to save to CWD or
%windir% when using the launcher to add games.

BTW, Fingolfin, if your around and have a moment to spare, could
you hop on IRC?

comment:14 Changed 15 years ago by fingolfin

No, you didn't explain it. You explained why reading the config from
windir generally is a good idea (and nobody disagreed). You then
proceeded to state that you can't imagine why somebody would want to
read the config file from CWD instead. Several people explained
scenarios why this could be useful.

So I stand on my point, you did not explain why you are totally opposed
to it :-). Still waiting for the reasoning behind that.

Finally, no, I can't hop on IRC right now -- IRC is a time sink and I have
some deadlines to meet before I can risk that =)

comment:15 Changed 15 years ago by fingolfin

* Contrary to what Ender stated, the request doesn't ask for the settings
in a second .ini being "appended" to the primary .ini's settings. Nor do I
like that idea at all: it's a nightmare to implment, and opens up a can of
problems.

* I still am waiting for the explanation as to why a fallback to a config
file in CWD is such a big problem. The only actual argument against it I
found on this item:
"I see no easy reason to decide whether to save to CWD or %windir%
when using the launcher to add games."
That's not really a problem. We can simply make an arbitrary decision.
I.e.: if there is already a config file, save to it, whever it is; if there is
none, save to %windir% (just as we do now, i.e. no change), but if that
fails (due to write protection of %windir% / lack of user rights), save to
current dir. No problem at all

* OTOH there is a nice reason why to do allow it: multi user machines:
you may not even have the permissions to write to %windir%. For the
very same reasons we don't write our config file to /etc/scummvm

* Ender also wrote:
"The default still is, and will always be, to search the 'global
location' (~ on *nix, %windir% on Win32). "
-> fine by me, no contradiction here with anything else said by me or
Kaminari. However it *is* self-contradicing: %windir% indeed is a
"global location", but "~" on *nix is not. BTW on Mac OS X we use "~/
Library/Preferences", which is user specifc (like on other *nix, but unlike
Windows).

* Ideally, it seems storing the config in the user's homedirectory on
Windows, too, would be the most natural solution -- however, not all
Windows versions have such a thing, of course. (And I am not a Windows
user normally, so I may very well be totally wrong here anyway).

comment:16 Changed 15 years ago by fingolfin

Ender, care to comment?

I'd like to at least hear the arguments against loading a config file from
the current dir, if present. And I threaten to simply add it if we again
don't hear anything from you during the next 1-2 months (I am not going
to wait 5 months again) <grin>

BTW, a very nice use of this would be making ScummVM-cds: Copy all
data files you like, ScummVM, and a scummvm.ini, to a CD. When
running ScummVM from that CD, it'll load the "local" config file. Voila,
100% plug and play for your CD. You can take it with you if you go to
visit a friend, insert it, and start playing. Or, use an USB stick instead of
CD, then you can even store your savegames. :-)

[Although the above is hampered on Windows a bit by the fact that those
silly drive letters may vary from machine to machine. Bah]

comment:17 Changed 15 years ago by fingolfin

Owner: fingolfin deleted

comment:18 Changed 15 years ago by SF/jamieson630

Well, the game paths would just have to be relative as well.

./games/dott/
or
../games/dott/
etc.

I condone support for a current directory config file
because it also allows users of a multi-user Windows
environment to have their own configurations. One user may
like to play in a window, another user may like to play
fullscreen. They may prefer different scalers, subtitle
configurations, etc.

The use of C:\WINDOWS to store config files is simply
archaic. Config files should use a path starting with
%USERPROFILE% for per-user settings or %ALLUSERPROFILE% for
global settings. Since these environment variables probably
don't have any meaning in Linux et al, a means of
abstracting the concept would be useful.

comment:19 Changed 15 years ago by fingolfin

Is there a Windows API to query these "%USERPROFILE%" etc. values?
I.e. to get an actual path out of those?

comment:20 Changed 15 years ago by SF/jamieson630

You SHOULD be able to use environment variables in regular
file system calls as part of the path string, e.g. fopen
("%USERPROFILE%\\scummvm.ini");

If not, however, the Windows API includes the following
function to expand an environment variable to its mapped value:

DWORD ExpandEnvironmentStrings(LPCTSTR lpSrc, LPTSTR lpDst,
DWORD nSize);

lpSrc being the pointer to the source string, lpDst being a
pointer to where the output string should be written, and
nSize being the maximum number of characters the output
buffer can hold.

Since we're still supporting pre-NT incarnations of Windows,
we have to be careful which environment variables we use.
Many environment variables are not available on earlier
versions of Windows, though I found it devilishly difficult
to nail down which ones are supported by which version of
Windows. Therefore, a sequence of possible environment
variables should be tested to see if they come back blank.
If not, they can be used, otherwise move to the next
alternative.

For per-user settings:

%APPDATA%
(The full drive/path to application data for the current user.)

%USERPROFILE%
(The full drive/path to the user's profile area, in which
case scummvm.ini can just sit there instead of %APPDATA%,
which usually maps to "%USERPROFILE%\Application Data" anyway.)

%HOMEDRIVE%%HOMEPATH%
(Combination drive and path to the user's home area, which,
if defined, should equate to the exact same path as
%USERPROFILE%.)

Otherwise fail for per-user settings.

For global settings:

%ALLUSERSPROFILE%
(The full drive/path to the settings for all users and
duplicated for all new user accounts. Too bad there's not an
"All Users" equivalent of %APPDATA%....)

%WINDIR%
(The full drive/path to the Windows directory. What we're
using now; it should remain a backup if the newer
%ALLUSERSPROFILE% is not available.)

Otherwise fail for global settings.

http://www.winntmag.com/Article/ArticleID/23873/23873.html
provides a list of environment variables available on
Windows, but does not specify which versions of Windows
support which variables. I could only find snippets on the
Web indicating support (or lack thereof) for different
variables on various versions of Windows.

So... uh... should we encapsulate OS-specific stuff like
this in convenient getUserConfigFile() and
getGlobalConfigFile() methods somewhere?

comment:21 Changed 14 years ago by fingolfin

Summary: WIN: Append current directory's config to the global configWIN: Look for config file in multiple places

comment:22 Changed 14 years ago by fingolfin

"encapsulate OS-specific stuff like this in convenient
getUserConfigFile() and getGlobalConfigFile() methods" like a
good idea, Jamieson630.

Though I am actually not in favor of allowing a "mix" of active
config files. One config file should be active at a time. We just
should try out multiple locations - like e.g. unix shells do for
their config files (they look in multiple places for a config
file, using the first they find; first they look for a user
specific one, then for system wide ones).

In fact, ConfigManager::ConfigManager() (in
common/config-manager.cpp) alread does different things for
differen systems...

comment:23 Changed 14 years ago by SF/benshadwick

IMHO, no programs should place config files in the system
directories because it makes a mess (and that's what the
registry was created for).

In the Windows version at least, ScummVM should just use the
current or ScummVM executable directory as the default
config file location (as is standard behavior for almost all
Windows apps and games these days that use config files
instead of the registry). This way, users on a LAN or
multi-user machine can run the game from a shared location
and have access to the same configuration file without
having to mess with shortcuts, environment variables, or
copying stuff around.

I also think using environment variables is a bad idea,
unless you're dead-set on the idea of looking in the user
profile directory. I personally don't like software that
dumps stuff there though because it isn't easy to find.
Additionally, it would be trivial to create a .BAT file (or
maybe even a shortcut) to pass the USERPROFILE value to
ScummVM to tell it where to put the config file if such
behavior is desired.

I think we should go for the clean, simple option and just
look in the current directory first on Win32 - just like
most other apps do. Please don't scatter files all around
the system and make it unfriendly to LAN users by default...

To help move things along, I played around for a few minutes
and submitted a patch in hopes that it will inspire someone
to make an official change to the code.

Peace.

comment:24 Changed 14 years ago by fingolfin

I think you misunderstand jamieson regarding the env
variables. This is not about letting the user specify some
funky env vars to modify where we look for config files,
rather, this is about using standard windows env settings and
a standard Windows API to query where user profile data etc.
is located.

So a proper patch would query the Windows system for the
location it should look for a config file (the "user profile
directory", or whatever it's called).

Anyway, I claimed I wouldn't wait another 5 months -- that was
7 months ago *cough*. I am going to handle this now.

So, what I propose to do is this:
0) Use the config file the user specified on the command line;
if that path was invalid, abort.
1) Look for config file in the CWD
2) Failing that, look for config file in some user specific dir
(userprofile on windows, home dir on Linux,
~/Library/Preferences on OS X, whatever, TBD)
3) Failing that, look for scummvm.ini in some global location:
windir, /etc, /Library/Preferences

For saving settings:
1) If we started with an existing config file, try to use it.
2) If that fails (no file was specified, or it is read-only),
and we used a global config so far: create a user specific
config file.
3) Otherwise (we were using user specific or CWD config file,
and failed to write to it), show an error dialog to the
user; maybe abort, or keep running but tell the user that
settings won't be saved

As you can see, we'll never create a config file in CWD, but
if present we use it. Hence we allow "power users" a CWD config
file, but regular mortals won't be bothered by this "feature".

comment:25 Changed 14 years ago by fingolfin

Looks to me as if we might want to use the
SHGetSpecialFolderPath() and/or SHGetFolderPath() functions of
the WinAPI. Look at MSDN for detailed information.

In particular, these might be of interest for us (not just for
the config files, but also for things like the MT32 sample
file etc.):
* CSIDL_APPDATA / CSIDL_COMMON_APPDATA
* CSIDL_PERSONAL (although this seems to be a "virtual" folder
in newer system versions, so not usable?)
* CSIDL_PROFILE

To quote the MSDN docs:
"Some CSIDLs can be mapped to an equivalent %VariableName%
environment variable. CSIDLs are more reliable, however, and
should be used if possible."

An advantage of the env variables is that we can check for
them on all and any Windows version; the drawback is that
they do not exist on all Windows versions, and so far I
haven't found any "hard" information on their availability.

comment:26 Changed 14 years ago by SF/benshadwick

fingolfin: I agree with your proposed solution, with two
caveats:
1. I think that if a config file is specified on the command
line and it doesn't exist, SCUMMVM should either exit with
an error message or create a new config file with that
name/location. If this doesn't sound appealing then the user
should at least be adequately informed that SCUMMVM went
behind his/her back and made a file somewhere else.
2. I've read all the comments here and I still side with the
argument(s) for having the config file default read and
creation locations default to the directory that SCUMMVM is
run from (at least on Windows). Most of the reasons have
aleady been mentioned, but I'd like to weigh in anyways just
for the heck of it:
- the vast majority of Windows users will be running in a
single-user environment and will be using the launcher to
configure SCUMMVM to use all their SCUMM data files. In this
case, it's much cleaner to just keep all of SCUMMVM's stuff
in its own directory
- very few entertainment applications store data in
user-specific folders in Windows, and I personally find it
annoying when they do because it means scattering files
around the filesystem that get left behind when I uninstall
the game. I guess the real argument here is: all things
being equal, it's probably best to implement behavior that
is consistent with other similar software available for the
same platform (i.e. have the program keep its configuration
data in its own directory by default when running under Windows)
- you can create a shortcut or batch file to have SCUMMVM
look for its config file in users' home directories (not
really an argument, admittedly, as you can just as easily
use the same mechanism to have SCUMMVM look in its own dir,
as I currently do on my own LAN)
- I found the argument for relocatability of the SCUMMVM
install directory a strong one, until I discovered that you
can specify relative paths for everything in the config
file. As a result, if you have your config file in the
SCUMMVM directory and all your game data files in
subdirectories of that directory (as I do), then you can
move the whole SCUMMVM directory around at will without
reconfiguring anything
- your (fingolfin's) own argument about being able to make
SCUMMVM CDs is valid, considering you can use relative paths
in scummvm.ini!

On a side note: If you're going to store the scummvm.ini in
a user folder, then you should go all the way and store save
files there by default too. It makes a lot more sense that
an admin on a multi-user system would want to set up the
config file in a central location and then have the save
files go in user-specific locations than vice-versa.

Closing thoughts:
- In the end, I can live with any behavior as long as I can
still override it with command-line parameters.
- I'm very grateful that you've decided to come back and
address this issue :)
- It probably is a good idea to still look in the windir as
a fallback, for people that don't read the readme if/when a
new version is released with new config file behavior
- Sorry for the long, rambling post. I wrote it in two
sittings, so I had a long time to mull it over

comment:27 Changed 14 years ago by sev-

This issue was raised and discussed for several times now.
In every case we came to conclusion that this feature will
bring more problems than benefits.

For different scummvm settings use -c command line switch flag.

Rejected.

comment:28 Changed 14 years ago by sev-

Owner: set to sev-
Resolution: wontfix
Status: newclosed

comment:29 Changed 13 years ago by fingolfin

I just noticed that this item was closed.

I disagree with this, and I explained my reasons in detail in various comments
to this tracker item. So far *nobody* properly responded to them, nor do I
recall a proper discussion anywhere else.

The original request is indeed suspicious, but the notion of moving the .ini
out of the WINDOWS directory not only seems logical to me, but indeed in the
current days it is a must, because people shouldn't run their Windows XP
boxes as admin, but rather as a user with limited rights, for security reasons.
This is currently limited by stupid apps (which, in this case, unfortunately
includes ScummVM) that only run with admin rights.

As such, I am reopening this item.

See also Bug #1384527 (might soon be moved to RFE tracker).

comment:30 Changed 13 years ago by fingolfin

Owner: sev- deleted
Resolution: wontfix
Status: closednew

comment:31 Changed 13 years ago by Kirben

I really don't see the problem, I expect most gamers would
be logged on as administrator, due to older games requiring
it.

If people want the config file in another location, it can
easily be set by the command line options.

I don't think any of the enviromental variables listed
would be useful, since they don't exist on Windows 95.
Windows 95 itself only provides the current Windows
directory, via %windir%.

Using SHGetSpecialFolderPath() and/or SHGetFolderPath()
would be best avoided too, since the minimum requirement is
Windows 95 with Internet Explorer 4.0 added.

If we change the default location of the config file on
Windows, the default location should be the same on all
versions of Windows.

Considering we still support Windows 95, the only real
options are the CWD and current Windows directory.

comment:32 Changed 13 years ago by SF/joachimeberhard

I just add my post from a different request, where %
appdata% is recommended as location for scummvm.ini

Somehow I think %appdata% isn't such a good idea.

%appdata% is a hidden path and not so easy to find for
people just wanting to back up their settings....

I'd much rather prefer %homepath% or %homepath%\ScummVM to
be the directory of the ini files which is the "My
documents" shorcut.

You could also place the savegames there by default, to
avoid the CD-Access issues you're concerned about...

%homepath%\ScummVM is also the way most modern games would
store their savegames, so I'm very much in favour of this.

If you're wanting to make things really a better default
experience for windows users, this is my suggestion for
it...

Best regards

Joachim

comment:33 Changed 13 years ago by sev-

What is the status of this item?

comment:34 Changed 13 years ago by SF/andrej4000

Patch #1476081 provides the functionality for storing
scummvm.ini in the user profile on NT machines in a simple
way. It uses only the Win32 API that was already present in
Win95 times, so no compatibility should be lost.

comment:35 Changed 13 years ago by fingolfin

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).

comment:36 Changed 13 years ago by fingolfin

Oops, that last comment was meant for <https://sourceforge.net/tracker/
index.php?func=detail&aid=1476081&group_id=37116&atid=418822> --
sorry.

comment:37 Changed 13 years ago by sev-

What is the status of this item?

comment:38 Changed 13 years ago by fingolfin

What should the status be? Of course it's the same it has been all the time
before :-). We have some good reasons to move the config file, a patch was
submitted for it, and we need to discuss what we want to do, in particular, some
of our Windows coders need to be involved ...

comment:39 Changed 13 years ago by SF/joachimeberhard

I copy over my forum post here to push this dicussion to
finally some solution.

Personally, I consider this circumstance neither to be a
feature request nor a bug, but simply as a horrid
violation of a principle Operating System design guide.

scummvm.ini AND the savegames *have* (I say have here to
stress it) to be stored in %homepath%\ScummVM.

%appdata% is in no circumstance suitable for non-technical
users, to stress again, in really absolutely NO
circumstance, as it is per default a *hidden* path, not
intended to be manipulated by the ordinary user. Also, it
would provide us with lots of questions, where a user
could regain his savegames, after he
reinstalled/moved/restored his PC.

Also, as pointed out above, %appdata% is ALSO protected by
Windows System recovery. That means, by using a restore
points, you'll lose your savegames and settings. this will
NOT happen with %homepath%\ScummVM, as sysrecovery
prevents that.

%homepath%\ScummVM would be compatible with the following
OSes:

Win95+IE5,WinNT+SP5,Win98,WinME,Win2000,WinXP,WinVista

The current location is 100% compatible with the following
OSes:

Win95,Win98,WinME

What more do we need to say?
PLEASE!
PRETTY PLEASE WITH SUGAR ON TOP AND CHOCOLATE SPRINKLES!

comment:40 Changed 13 years ago by SF/ender

If there was a well tested patch (ala #1476081), but proven
to work on all Windows from 95 (without IE5) to 98SE it
might actually happen.

Read over Fingolfins comments on Andrej's patch and come up
with something clean and 100% tested? :)

comment:41 Changed 13 years ago by SF/ender

Or vinterstums new (but equally untested) patch #1511993
that he just posted. :)

comment:42 Changed 13 years ago by Kirben

On Windows NT/2000/XP/Vista, the search order is now:
1) Look for config file in the 'Application Data\ScummVM'
directory of the user's profile
2) Look for config file in the Windows directory

The default config file location is the the 'Application
Data\ScummVM' directory of the user's profile, if no config
file exists.

The location of the config file on Windows 95/98/ME is
uneffected.

comment:43 Changed 13 years ago by Kirben

Owner: set to Kirben
Resolution: fixed
Status: newclosed

comment:44 Changed 6 months ago by digitall

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