Windows Equivalent of System Configuration Directory

Question

I am developing a CLI application in Ruby, and I'd like to allow configuration in Unix via the standard config file cascade of /etc/appnamerc, ~/.appnamerc. However, the application is also meant to be run in a Windows environment, and I'm unsure of where one would put a file like /etc/appnamerc (C:\windows\system32\etc\drivers does not seem like it would be the correct place). Further, whatever scheme I decide for looking up a system configuration file also needs to consider the different versions of Windows, i.e. C:\Users vs. C:\Documents and Settings. As far as user-specific configuration goes, I am also unsure of where to have my application look for a user-specific configuration file, and what the standard naming convention for something like that would be.

Answer 1

Windows defines several special folders that can be accessed using the SHGetSpecialFolderPath API. I would suggest using one of these folder locations.

For example here is how to get the common application folder location:

char szBuffer[1024];

// get the common application data folder
::SHGetSpecialFolderPath(0, szBuffer, CSIDL_COMMON_APPDATA, false);

Answer 2

You should use the shGetSpecialFolderLocation function. which specific constant to pass it -> CSIDL_COMMON_APPDATA, CSIDL_LOCAL_APPDATA, CSIDL_COMMON_DOCUMENTS or CSIDL_PERSONAL

is a matter of debate. see: http://www.icetips.com/blog/index.php/2008/10/31/title

for more help

Answer 3

What you're looking for is the SHGetKnownFolderPath function (or—on older versions of Windows—the SHGetFolderPath function).

While Windows has conventions what those paths are and where they reside this is entirely dependent on version, configuration and other factors so hard-coding folder names is a bad idea. Above function has been the way to get those “special” folder locations since the beginning, though.

The main argument to those functions is either a KNOWNFOLDERID or a CSIDL which specify which folder you want to get.

You have two different “flags”, actually: User-specific and machine-specific on Windows. A location can be specific to a single user or available to all users and it can be specific to a single machine or be available on all machines the user has access to. Those will be distinguished below.

The ones you do want here are the following:

• FOLDERID_ProgramData/CSIDL_COMMON_APPDATA: This is for program settings for all users, so approximately the equivalent of /etc/foorc. You should create a directory for your program there and store your all-users config there. Note that this directory is not writable for normal users (just like /etc is too, I think). This directory is machine-specific, though.
• FOLDERID_RoamingAppData/CSIDL_APPDATA: This is for user-specific settings or application data. For most use cases this should be the primary place where you put this because it will be saved in the roaming profile—therefore it's accessible on every machine the user logs on. So this is the equivalent of your ~/.foorc. The same rules as for the all users variant apply.
• FOLDERID_LocalAppData/CSIDL_LOCAL_APPDATA: This is the machine-specific location for user-specific data. Usually this should be used for things like caches which are nice to have around but are not necessary to copy over the network every time the user logs on. Note that Thunderbird gets this very wrong in storing the local copy of IMAP mails in the roaming profile—this is kinda fun when you have several GiB of data in there.

Generally, please avoid just sticking your .foorc in the user's profile folder. Windows is not UNIX and files preceded by a dot are not automatically hidden (there is a file system flag for that). To me it's just an annoyance if applications do that because the user's profile directory is not the place for that kind of thing on Windows. Likewise, the Documents folder is not a good place for applications to create stuff without the user's consent or explicit action.

From Ruby you should be able to call those functions using the Win32API library. This looks vaguely promising (though ugly); however, I don't know enough to actually show you a working example.

A last-resort option would be to use environment variables. The environment variables ALLUSERSPROFILE, APPDATA and LOCALAPPDATA are the respective equivalents of above FolderIDs.