views:

69

answers:

1

I am looking for an acceptable starting point for placing applications settings in a Windows machine. I have more than one application. for personal reasons, I wouldn't like to use the registry: I prefer plain text initialization files (.ini). I also don't feel like holding the files in the same directory as the executables, the ideal situation allows me to keep them somewhere generic where users or system administrators are allowed to write.

right, I'm not a windows user, my first guess would be $HOME/.my_company_name and /etc/my_company_name, but is there something conceptually equivalent to these places in Windows?

just looking into the SET output and guessing:

%APPDATA%
%HOMEDRIVE%%HOMEPATH%\Local Settings
%SYSTEMROOT%

by the way: I still must check whether these variables still exist from within a windows service...

+3  A: 

I think AppData is what you want.

You can use SHGetFolderPath (from SHFOLDER.DLL) to get this programmatically.

From MSDN 'Data and Settings Management' (see section 4.2 'Classify and store application data correctly'):

TCHAR szAppData[MAX_PATH];
…
hr = SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, szAppData);

Append [company name]\[product name]\[version] to szAppData using PathAppend:

PathAppend(szAppData, "Company\Product\1.0\File.ini")

There is also CSIDL_COMMON_APPDATA for non-user specific data and CSIDL_LOCAL_APPDATA for non roaming data (data that shouldn't be copied across the network when user logs on to a different machine).

danio
I agree. That folder also roams with the user over the network if roaming is turned on.
Christian Hayter
thanks for the hints. I ended up writing a function that reads an INI file into a map<string,map<string,string> > dictionary and calling this function twice, once for CSIDL_COMMON_APPDATA and then with CSIDL_LOCAL_APPDATA.szAppData does not end with a \. is that WXP specific?
mariotomo
There is a win32 api to read ini files: GetPrivateProfileString (http://msdn.microsoft.com/en-us/library/ms724353(VS.85).aspx)If you use PathAppend then you don't have to worry about whether it ends in a \. Welcome to the win32 way: it's all or nothing...
danio