Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects


Blog Archive

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:

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.


This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.