The Windows Registry, which dates back from Windows 3.x cops a lot of flak. The registry, if you’re not familiar with it, is a central database where Windows and most programs store their settings. It is organised in a rough tree structure and supports a few basic data types.
The main complaint is that because the registry is typically because it is typically tied to a Windows installation. When your Windows installation dies or otherwise needs replacing – not an uncommon thing – you lose all your settings in the registry. Since applications depend on settings being there when they are loaded, they’ll often crash and die on startup. So even though you’ve got an application’s files on your computer, you won’t be able to use it until it’s reinstalled. This is a pain.
What I think is great about the registry is the seamless multi-user support (i.e, HKEY_CURRENT_USER) but most importantly the openness of it. You can interact with the registry in pretty much any way you want. As a developer you can hook into various system settings or application preferences or even make your own modifications. Access is standardised, and there are well established norms about the structure of registry keys. Furthermore, there are basic discovery abilities – you can traverse the registry in code without really knowing what specific key you’re after. For example, in Windows I can easily, as a 3rd party pull up the proxy settings Microsoft Internet Explorer is using. I can also, should I want to, make changes to this setting easily using any number of tools or APIs. If I wanted to do the same for Firefox, I’d have to determine which FF profile to read by opening a INI file and then parse a JavaScript (!) file for the setting I’m after. No-where near as elegant.
The prevalent alternative to using the registry for settings is to store data in individual files, on a per-application basis. Some apps use old-school INI-style files, some XML others serialized binary data. The problem with this is that each store is an island, or worse, a walled fortress. And since each application uses a different format, and may even vary from version to version it’s quite the challenge to write external code which may make use of these settings.
For sure the registry as its flaws, but I think the open, common-platform approach is very sound, and badly lacking from the alternative method. Better coding by application authors would mean that apps would behave more gracefully should their expected registry keys be missing, and this would go along way in reducing the headaches associated with the registry. Having some kind of ‘portable’ registry system whereby settings can be kept ‘physically’ with an application, yet synchronised with a central store would also be a boon.
