views:

255

answers:

5

OK, true confession first: Maybe it's just me, but sometimes "best practices for program settings" on Windows machines feels like it's changed more than Microsoft's data access strategies. I'm still running XP, and somewhere along the way just kind "glazed over" about where MS wanted me to store all my app's data, etc. I controlled all the machines I coded for, so it really didn't matter.

Now I'm writing apps for "in the wild," supporting Win98SE on up. I have to pay attention to all this again. :-\

For reasons having to do mostly with easy migration to new computers, I'm not a big fan of using the registry for app settings -- I prefer using INI files, and have some older INI components that I use for the task (Raize, usually). I'm open to suggestions to other third-party components, if they'll make this easier / less hassle.

Basically, I need to store app settings (like remembering option settings, etc).

I've read: http://stackoverflow.com/questions/6607/registry-vs-ini-file-for-storing-user-configurable-application-settings
http://stackoverflow.com/questions/285277/where-to-store-program-settings-instead-of-hkeylocalmachine
http://stackoverflow.com/questions/579673/where-should-my-win32-program-keep-its-files
http://stackoverflow.com/questions/269893/best-place-to-store-config-files-and-log-files-on-windows-for-my-program

...so at least I'm not alone in this question... ; )
(w/apologies for what is somewhat of a repeat question, albeit from a slightly different angle).

It SOUNDS like I can just use %APPDATA%/MyProgram, and store all data there, BUT is this UNIVERSALLY TRUE across all Windows flavors from Win98SE on up? If not, what's the best approach, and when did that approach come into existence?

What I'm really looking for, honestly, is the easiest way to make this problem go away -- I just want one (if possible), simple, easy, reliable way to grab "My Program's Data Folder" in any and all instances. Will the above accomplish that?

A: 

I can't comment on whether it works on all versions but I certainly agree that .ini files are the right answer. When XP said to use the registry I tried it--for one program. In-house deployment showed that the settings needed to be copied from machine to machine--the next update was back to .ini files.

I think the whole registry bit was an anti-piracy measure of theirs that they wanted hide as a best practice.

Loren Pechtel
Registry settings can be exported into a text file, commented and copied around easily using the reg/regedit utilities.Another advantage (apart from hierarchy, backup, security, data types, or ACID on NT6) is that you can transfer only differences to a base state.That is impossible with text files.
jachymko
Sure, if everything were neatly in one branch. Microsoft stuff never is. Walk up to an existing installation of an app and you can't hope to find all the stuff you need to copy off.
Loren Pechtel
I used to love the registry but it just became too much hassle and I would go back to ini files for anything but a major application. I think they created it to get over the 32k limit of ini files on win 95/98
Toby Allen
+3  A: 

%APPDATA% doesn't seem to be present on Win95. I would use SHGetSpecialFolderPath which is available on Win98 or Win95 w/IE4.

jachymko
+4  A: 
Bob S
I'd seen that article in my research, but didn't know how "universal" that solution was. Your "IE 4" clarification here is really helpful. Thanks!
Jamo
A: 

I tend to use xml files in %APPDATA% to hold my settings. Only really because xml is easier than ini's for C#. Regardless, %APPDATA% does seem a safe bet.

I can't advise on whether 98SE supports this.

Dan Revell
+2  A: 

The answers you got so far are good, I think however that you are mixing things in your question that don't belong together, so it's not possible to completely answer your question.

Your question title states

INI-type settings and/or DB files

and these can be two quite different things. You have to differentiate between files that are per-user, files that are common for all users but read-only, and common files that every user should be able to work with.

The first category is easy, use a suitable directory under one of the CSIDL_APPDATA or CSIDL_PERSONAL folders.

The second category is also easy, files just need to be installed in the proper location by the setup program, which must be run with proper permissions, because standard (limited) users will not be able to write to the correct locations.

The last category however is difficult, because there simply isn't a directory in all Windows installations that can be assumed to be writeable for all users. Especially in business settings with locked-down user accounts it can be that the user has no write permissions for the local disc at all, only to their user directory somewhere on a server in the network. So there is no single simple way to grab that data location for your program and be sure it will work - it's something you will possibly have to revisit for all programs and all use cases anew.

For bonus points you should also always consider whether the files should go into the roaming profile and be available on all machines in a domain, or whether they are machine-specific.

One tip I would give is to move away from desktop style database files like Paradox or Access files for applications that need to share data between users on a machine. Only with real (local) database servers will you be able to have multi-user data on locked-down accounts / machines.

mghie