#7273 closed feature request (fixed)
WIN: Look for config file in multiple places
| Reported by: | SF/itsr0y | Owned by: | Kirben |
|---|---|---|---|
| Priority: | normal | Component: | Port: Win32 |
| Version: | 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 by , 22 years ago
comment:2 by , 22 years ago
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 by , 22 years ago
| Summary: | WIN: Move scummvm.ini to current directory → WIN: Append current directory's config to the global config |
|---|
comment:4 by , 22 years ago
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 by , 21 years ago
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 by , 21 years ago
| Owner: | set to |
|---|
comment:7 by , 21 years ago
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 by , 21 years ago
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:10 by , 21 years ago
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:12 by , 21 years ago
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 by , 21 years ago
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 by , 21 years ago
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 by , 21 years ago
* 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 by , 20 years ago
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 by , 20 years ago
| Owner: | removed |
|---|
comment:18 by , 20 years ago
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 by , 20 years ago
Is there a Windows API to query these "%USERPROFILE%" etc. values? I.e. to get an actual path out of those?
comment:20 by , 20 years ago
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 by , 20 years ago
| Summary: | WIN: Append current directory's config to the global config → WIN: Look for config file in multiple places |
|---|
comment:22 by , 20 years ago
"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 by , 20 years ago
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 by , 20 years ago
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 by , 20 years ago
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 by , 20 years ago
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 by , 19 years ago
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 by , 19 years ago
| Owner: | set to |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
comment:29 by , 19 years ago
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 by , 19 years ago
| Owner: | removed |
|---|---|
| Resolution: | wontfix |
| Status: | closed → new |
comment:31 by , 19 years ago
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 by , 19 years ago
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:34 by , 19 years ago
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 by , 19 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).
comment:36 by , 19 years ago
Oops, that last comment was meant for <https://sourceforge.net/tracker/ index.php?func=detail&aid=1476081&group_id=37116&atid=418822> -- sorry.
comment:38 by , 19 years ago
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 by , 18 years ago
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 by , 18 years ago
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 by , 18 years ago
Or vinterstums new (but equally untested) patch #1511993 that he just posted. :)
comment:42 by , 18 years ago
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 by , 18 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:44 by , 6 years ago
| Component: | → Port: Win32 |
|---|
Why don't you simply make a shortcut to scummvm.ini?