§ ¶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.
Comments
Comments posted:
That's what I did in Zoom Player, but as an added bonus, I made it possible to specify the config file by command line, making it very easy to have multiple separate configuration profiles that don't interfere with each other (I also made it that if the config file is specified in command line then all data was saved in a separate registry tree, exported and then erased on exit)
Blight (link) - 04 07 10 - 10:01
I think, portable settings are best thought of as documents and handled similarly. Applications that want to handle settings portably often have additional options to save and open their databases.
Alexey - 04 07 10 - 13:02
Keeping the settings in a .ini also helps to reduce windows rot/registry bloat.
asf - 05 07 10 - 04:08
Registry rot/bloat hasn't been a problem since Win9x ceased to (practically) exist...
KaarlisK - 05 07 10 - 05:55
@KaarlisK are you crazy? First off, the registry is a memory mapped file or kernel paged pool (depending on windows version) so its size is going to have some sort of impact. Go take a look @ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components etc and tell me that is not bloat that really should be stored in a external file?
asf - 05 07 10 - 06:10
If you're going to take that stance, then by that argument nothing should go in the registry. Memory-mapping a 9MB file is not such a big deal, especially with many of the pages aren't touched. I have to side with KaarlisK on this one -- registry bloat hasn't been nearly as much of a problem as it was in the Win9x days, where the kernel had issues reclaiming space from deleted entries. Remember that if programs don't use the Registry they have to roll their own solution for concurrent, stable storage, and that introduces another form of bloat. Would you want Windows Installer to create a file per entry instead? That's what the Internet Explorer guys did for bookmarks....
Phaeron - 05 07 10 - 07:13
Well, yes, I'd rather they stuff that stuff as files in %windir%\installer\components or whatever, but since MSI is a database they already have some sort of database api and should use that and not single files (How often do you install/uninstall stuff?)
Vista+ has RegLoad/Save apis that non admins can use, but yes, windows really needs a config api that is just a mini registry in a file thingie
asf - 05 07 10 - 07:56
What about the defragment implications of always changing a 9Mb (says who?) file, even if the change is just one letter? IE's approach is why the Favorites are portable as well as editable externally.
lwc - 05 07 10 - 10:47
I'm not sure what you mean by defragmentation implications. Rewriting a file in place doesn't involve any disk space allocation and is ideal; extending a file has defrag implications, but it's no worse than creating new files. Generating lots of little files is AWFUL if you need to scan them -- it can take minutes to read all of the files. It does have the advantage of allowing the shell to manipulate the entries, though.
The 9MB figure is just the size of the SYSTEM.DAT hive on my computer.
Phaeron - 05 07 10 - 12:12
I'm sure mapping 100+ MB of registry bloat in Vista/7 surely does impact performance, especially on 32-bit systems. Running compcln.exe on Vista SP2, for example, improves system performance noticeably. I hope Win7 won't have such problems after several years, since registry APIs were improved there afaik.
Tihiy - 05 07 10 - 20:13
I wish you chose the INI model for being "Ghost" application (Portable).
Drazick - 06 07 10 - 21:16
There's one more advantage to registry - if I want to reset just one setting every time I start VirtualDub (Shutdown after jobs finish) I can do it using simple registry file instead of doing search/replace in an ini file which is not really supported by windows tools.
So I hope either this setting gets fixed or running VD without the ini file will still be an option in the future.
Kasuha - 08 07 10 - 22:06
I cannot count the amount of times I've had to load registry hives from old operating system installs just to transfer my program settings. Programs that use the registry to store settings are nothing but a hassle to me. I use portable programs any chance I get to avoid future complications.
In an ideal world, I would have all programs give the option of choosing the Registry or INI files to save settings, not force it upon the user.
DAOWAce (link) - 10 07 10 - 04:48
Why dont you use sql for data storing? LiteSQL perhabs? I would not use INI but SQL anytime.
Jeroi - 01 09 10 - 00:50
And tbh, aplication data folder these days serves as userprofile files. You can store setting file for each user in appdata folder or use main setting file on every user folder. This way works firefox and the rest main opensource programs. By default you check if no userfile on user folder then you generate default settings for that user. Then user defines his own settings. There is no need for windows registry anymore as appdata+SQL makes perfect pair.
Jeroi - 01 09 10 - 00:57
Hi, this is slightly O/T but one thing about VirtualDub that I find very annoying is we cant save capture settings into a config file the same way we can save render settings into a .vcf file. I use virtualdub to capture from various sources and I use settings specific to each source. i.e. my settings for an easycap are not the same as capture from desktop capture, also my eascap settings for xbox are no the same as my easycap settings for PS1 etc.
My current workaround is to write the capture settings I want to use into the registry and then launch the virtualdub executable, but it would be nice if we could have a command line to load capture settings from say a .vcs (VirtualDub capture settings) file.
Mark - 02 09 10 - 01:59
Registry settings can be dumped into *.reg file using something like "regedit /ea filename.reg HKEY_CURRENT_USER\Software\MySoftware\MySettings" and then restored back just by "executing" reg file. This helps backing up settings in some applications.
Vlad - 12 09 10 - 19:20
Vlad, or using regedit gui, browsing to HKEY_CURRENT_USER\Software\MySoftware\ and clicking on export selected branch.
brontosaurusrex - 30 12 10 - 00:45
