¶The Windows registry vs. INI files
I've been asked a few times over the years why I use the Windows registry to store settings instead of INI files. The main answer is that it's a cleaner and easier to use interface for storing settings. The registry certainly has its faults, but it has a number of advantages as well:
- It cooperates with user profiles. The registry contains portions that are both per-machine (HKEY_LOCAL_MACHINE) and per-user (HKEY_CURRENT_USER). Data put in HKCU automatically works with multiple users, roaming profiles, profile backup/restore, etc.
- It has a key/value interface that does not require parsing. You can put arbitrary data into the registry without escaping.
- It already has a GUI tool for inspection and tweaking (regedit).
- The registry store is managed by the kernel. If your application hangs or crashes, changes to the registry are still committed. If the system dies, it's the responsibility of Windows to ensure that the registry is valid.
- Access to the registry is thread and multiple instance safe. Multiple threads and multiple processes can simultaneously access the same registry value and updates are atomic.
IMO, the last one is the biggest advantage. One of the problems with using INI files is that you have conflicts on the INI file if multiple instances of the same program are run from the same location; this is made more difficult by inability to queue conflicting file opens or atomically commit partial updates into the file. Using the registry means that you can exchange data between multiple running instances. For instance, if a dialog commits last used values, the same dialog in another instance can pick up the same values as the defaults. I'm slowly moving toward trying to have more data stored and retrieved "just-in-time" in this manner; it reduces the cases where settings unexpectedly revert, either because the program died before it could save settings on exit, or one instance exited and committed all of its settings regardless of which ones changed.
As for arguments against the registry, one is that it stores settings in one big binary blob in the user profile that's hard to manage and backup. That's definitely true, and it's unfortunate that Microsoft didn't provide a good way to isolate a branch of the registry in a separate file. You can use RegLoadKey() to do this to some extent, but it's unfortunately a global operation instead of a process-local operation and requires backup/restore privileges. The second is that you can manually tweak an INI file in a text editor. I'm not sure I buy that argument as much, as it's difficult to programmatically commit settings back to an INI file in a way that keeps them readable, particularly if you're persisting data structures. It's a bit like XML used as a serialization format -- I wouldn't call it human readable so much as human parseable.
There is one more argument against the registry and for INI files: portable operation. This is where settings are stored in a file next to the executable so both can be moved together. This does hold plenty of water, I have to admit. As a test, I added some experimental code into an Altirra test release that allows registry operations to be shunted to a virtual registry, which is then loaded from and stored to an INI file. The INI file looks a bit funny, but the advantage of doing it this way is that the program can run both in registry and in portable INI file mode. This seems to be working out pretty well, so I'm planning on back-porting that code to VirtualDub.