Anti-Pattern: Windows Registry

So Microsoft, back in Windows 3.x days, discovered that lots of software, when it installed or ran, needed someplace to store its persistent configuration data. And every bit of software had implemented its own way to do this. Usually using a unique flat file of some sort, and they often stored that file in the root folder, or sometimes in C:\Windows, or sometimes in their application's installation folder C:\MyProg.

So, I'm sure that they thought: hey, we can provide an OS level solution that will help developers by giving them a higher level API to use, so that they don't have to waste time reinventing the wheel, and creating their own "read configuration data" and "save configuration data" functions for every piece of software that comes out for Windows, and we can at the same time clean up the file system a little and help organize our customers computers by placing all of this data into a hive of configuration data. Heck, we'll need one ourselves, for all of our software (Microsoft's), as well as for the OS itself, so we'll kill like a thousand birds with one stone and everyone will be the better for it.

Its a well-intentioned, and good-in-theory idea. One that, at the time, I too thought was a "good thing"(tm).

However, over time it became increasingly obvious what the down-sides and limitations are to such an approach to the problem. First, there is the issue of fixing data when a configuration setting is bad / broken / wrong. This happens to software on occasion: say it recalls its last used window position from run to run, but you've had to downgrade your monitor while your good one is out to be repaired, and as a consequence, the window for this application is off the side of the screen and cannot be accessed. So you tell your customers: hey, just delete this setting from your configuration data, and everything will be fine! The application will initialize to defaults again, and all is well. But... the user needs to make this change to the very same registry that holds all of the variables that allows Windows to boot and run correctly! How often have users inadvertently changed the wrong setting, or otherwise made their machines broken or unbootable due to mis-edits in the registry!

Its just a bad idea to put application data (user-data) in the same space that the operating system uses for its very ability to function!

And when networking and user-profiles were attempted to be grafted onto the system, further problems cropped up and required that there be some of the registry hive stored as user-data, and other as system data, and the registry editor and APIs now have to navigate multiple hives behind the scenes to get it to all come out right, and it didn't always.

And I can imagine the fun it must have been at Microsoft when they realized that they needed to add security descriptors for every single hive address in their registry in order to have any ability to control the access to operating system protected parts of the system from the application's user-data portions. And how often over the years has registry security settings interfered with otherwise perfectly functional software? I know as a software user as well as developer that many, many, many times over the years our customers problems have resolved to: You deleted an account from your Windows PC and now some portion of your registry is utterly inaccessible to you or anyone on that computer, despite logging in as Administrator!

These are all nightmarish consequences of Microsoft's insistence on the registry as being the right way to store and maintain application settings. But to my mind, there is an even more basic an obvious reason that the registry is a bad idea: portability.

If I as a user want to move my settings, that I have invested real time and effort into configuring for myself, from one machine to another - say from office to home, or from an older machine to a new purchase, I often run smack into the walls put up by the registry.

I cannot simply copy my application's installation folder from one machine to another. I cannot navigate to a configuration file and copy it to the new machine. No, I have to somehow extract various settings from different parts of the registry and reassemble them on the target machine.

And how do I know what parts of the registry I'll need? I don't. Nobody does. Even software developers don't know all of the registry settings that their own applications use. Often times their installer, often written by another group or dept., will have a bunch of settings in addition to the many that the application needs. Its a common truth that many software packages fail to remove all of their entries from the registry when they're uninstalled. Perhaps a new registry entry was added between the time their installer or uninstaller was written and the various patches that were applied to the main application by the time it was uninstalled, hence rendering the uninstaller's log of what registry entries to remove long-out of date and incorrect.

If the application's data had instead simply been stored in the application's folder, then installation could be 100% accurate every time by simply deleting the folder, which is intuitive and obvious to any computer user, but which seems to be well beyond the grasp of the designers at Microsoft.

And when one looks at the problem overall, one has to wonder: Why was there an insistence on the registry? And why has it persisted all of this time? It seems to me that the dirty little secret is that many software publishers love it precisely because it does break their software when users try to copy it to a new machine! Free copy-protection, and they can blame Microsoft and claim that they aren't responsible at all. Its a Windows issue.

Well, one doesn't actually have to continue to use the Registry, and it really is more menace than aid. Its time we all admit it as a failure, and put our configuration data in a per-user and per-machine folder in a user-editable flat file, so that we can empower our customers to have clear and precise control over our software, and so that they have an easy mechanism for disaster recover, system migration, and backups that don't require a specialized knowledge and tool for extracting and restoring this information to/from the highly error-prone Windows registry.