Application Configuration and the Registry
Back in the bad old days, applications used INI files to store settings like where the main window was when it was closed, or the last font selected. Then, with Windows 95, Microsoft introduced the Registry APIs, and suggested that applications store their settings in the registry rather than in INI files.
One of the reasons for this suggestion was to support multiple users. Windows 95 didn’t have the concept of a home directory for a user, but there was the HKEY_CURRENT_USER key in the registry, and if you wanted to store per-user settings, that was the only place to do it.
I like the idea of having an API that abstracts away the storage of application settings, but in retrospect, the registry was a terrible way to do it.
The registry houses not only the settings for your application, but all of the settings for the entire system. How many times have you seen a page that instructs a user to use RegEdit to change some setting, but comes with a warning like:
Beware: Editing the registry can be dangerous. Backup your system before proceeding.
Sounds like a good idea, except that these pages never tell you how to back up the registry. There is no easy way. And why should I need to backup my whole system just to change some application setting. This warning is really just a way of saying “You’re about to do something dangerous; if you mess up, it’s not our fault – we told you to make a backupâ€. Nobody actually does it.
A Better Solution
Why did we move to the registry in the first place? Because there was no place to put per-user settings. With Windows XP, Microsoft introduced the horribly-named “Documents and Settings†folder, which contains a subdirectory for each user. Within Documents and Settings there is an Application Settings directory, where applications are free to create subdirectories and store files.
(Kudos to whoever decided that in Windows Vista, these names should be changed – in Vista, application settings will be in \Users\{username}\AppData. Much better).
The best way to store settings is in an XML file in the AppData directory.
The INI file APIs (ReadPrivateProfileString, WritePrivateProfileString) still exist, but I recommend using XML instead because of the richer expressiveness of XML, and the fact that you can create an XML schema to both document and validate the settings files.
Moving to a new system is much easier with settings stored in the user’s profile as files, since building a new system usually means copying over the user directory, but doesn’t involve migrating the registry.
If you’re using .NET then accessing configuration data via XML is actually easier than using the registry. There are some great references on storing app config, so I won’t duplicate that here. Read this for example. Note that this is really for configuration, not for settings – configuration in this case being things that an administrator might change, that affect how the program runs, and settings being things the user can change, like window positions.
For settings, there’s the Configuration Application Block. Docs are here, an example of how to use it here.
If you’re working in C++ and can’t use C++/CLI, then you’ll need to use the MSXML parser (or any other XML parser), which is a bit more code, but it’s still worth the effort. And once you’ve written the code once, you can use it anywhere. The trick is using SHGetFolderPath to get the base path for the settings, creating a directory in there for your company and product (take a look around the AppData directory to get an idea for how it works, it’s pretty straightforward), and then just writing to and reading back from XML files there.