Of the very many, very bad ideas in the world of software, the Windows Registry (“Registry”, below) is one of the worst. Among the many disadvantages (compared to config files a la Unix):
With config files, a user can typically specify which config file a program should use on the command line. In this manner, it is very easy and safe to test or use alternate configurations in parallel—including having the same application running with several different configurations at the same time. With the Registry, this is no longer possible. (Incidentally, leading to the “invention” of “profiles” which emulate the multi-configuration abilities with additional code and in a less user-friendly manner.)
A complication of such inflexible config repositories, especially in combination with config editing per GUI (or, even, with config editing per GUI regardless of back-end), is that running more than one instance of a particular application at the same time and with the same user account can be prevented artificially, because, God forbid!, someone might edit the config from both instances and cause an inconsistency—ergo, no-one must ever run more than one instance or the world will end.
The interoperability with other operating systems is reduced: Instead of an application having one single config format for all platforms, it now needs at least two—one for Windows and one for all other platforms. This leads to more developer time wasted; while at the same time preventing users from copying their configurations from one computer to another—including settings for servers/daemons.
(I suspect that this is a deliberate idea behind the Registry: This way companies are given incentives not to make their software available for non-Windows platforms...)
The contents cannot be edited with arbitrary editors, but need specialized and, incidentally, user-unfriendly tools. The disadvantages include cumbersome editing, less user-friendly full-text searches, and the inability to arrange the contents in a user specific manner.
I note that power users often prefer to edit files even when the application at hand has a built-in preference-editing mechanism (typically found under “Edit/Preferences” or a similar menu entry).
Various configuration-management tasks are made much harder (if not entirely impossible). Consider the saving in a central repository, sharing of config on several machines (not necessarily Windows machines!) or between several user accounts, dynamic generation of configuration based on templates, and similar. Such tasks can be quite important in a professional setting and do occur even for some private users. (I, e.g., put all important configuration in a git repository and have several private accounts on several private computers.)
The contents are much more cryptic and hard to understand than the average config file under Unix/Linux. Additionally, there is no possibility to add reasonable comments in the Registry it self (whereas many default config files contain extensive comments and suggestions—as do many publicized personal config files).
Adding configurability that goes beyond “key–value pairs” is much harder than with config files. Notably, many tools in the Unix-verse, e.g. editors like Vim/Emacs and shells like Bash/Ksh, have config files that amount to full scripts.
Damage done while editing the entries for one program can break the entire Registry.
The entries for the typical program are spread out in so chaotic a manner that even its de-installation program is often unable to find and delete all relevant entries. In contrast, under Unix it is usually enough to delete one single file or directory to be rid of all (user specific) configuration.
Over time, the Registry tends to blow up in size, and can actually become a performance problem in its own right.
Many of the above items are special cases of “unnecessary constraints on what the user can do” and more examples in this line can be found.
Further, this problem is very common with Microsoft products in general: Instead of enabling the user to do whatever he likes, he is given a limited set of options that Microsoft considers to be what he should do—and, for the rest, his hands are tied behind his back. He is disabled, not enabled.
Similarly, a common idea in Unix/Linux/FOSS development is that mechanisms and policy should be separated (and that policy should be left to higher “layers” than the mechanisms). Here, too, Microsoft products tend to follow the opposite line, and the Registry is at least a borderline example of this.
(Unfortunately, a Microsoftian attitude seems to be growing ever more popular even where saner attitudes used to reign.)
It provides a centralized mechanism for saving various settings, with no need for home-made storage formats and similar.
This is at best a half-truth, as it only holds for applications limited to Windows and, even with Windows, excludes tools that e.g. run from memory sticks with configuration on the memory stick. Moreover, complications like how to implement a config-file-as-script (cf. above) remain and might force Registry avoidance.
To the degree that it is true, this has nothing to do with the Registry in it self. Providing a corresponding interface for developers based on, e.g., traditional config files would have been less effort—without the disadvantages of the Registry.
The settings are in one central place, making administration and the like easier.
This is only partially true: They are central in terms of files; but so spread out within that file, that the benefits are more than lost. Additionally, again, this is not an inherent advantage of the Registry, but could easily have been achieved by conventional config files put in a central directory or directory tree.
Further, the user might well prefer not to have all settings in one place, but to be able to put them where he wants them.
Other advantages are sometimes cited; however, they typically refer to the replacement of the previous Windows-specific mechanism (INI-files), and are not relevant for config files in general. Notably, Microsoft is known for making comparisons only with previous versions of its own products, but not with competing products, which often have had the same or superior functionality for years (the most notable example being the DOS-to-Windows switch, where at least Unix, Next, Apple were all years ahead).
Unfortunately, there is a global trend towards less user-friendly config files (even where no Registry is present): Instead of seeing config files as a natural place for the user to express his wishes, most projects seem to see them only as a storage for settings changed over a GUI—or things that are not settings at all, but a preserved internal state of the application in question (e.g. window sizes, recently used files, and similar.) The consequences of this include e.g. that an application (notably, Firefox) might require the additional complexity and insecurity of a plug-in even when an extra line in a config file could have been enough. Further, many of the disadvantages mentioned above spread over to non-Registry config too.
Some general rules:
Internal state should be stored separately from true settings and configuration.
A GUI should be viewed only as an additional way to change settings—not as a replacement for the editing of config files. Editable config files are mandatory, and if an additional GUI is provided, the two should co-exist peacefully. In particular, the syntax, readability, and maintainability of the config files must not be compromised under the assumption that they will only ever be accessed through that GUI.
There are, of course, other approaches yet, e.g. to store config settings in an SQLite database. A thorough discussion of such approaches is well beyond the scope of this text, and they are not of great practical importance to my own computer use. However, I note that acceptability of such approaches might depend less on the central technology/paradigm/whatnot (e.g. SQLite resp. storage in a relational DB) and more on how the integration is made. For instance, an application could force a connection to a specific single-instance DB in a manner similar to how the Registry works—or it could allow the same choice between arbitrarily many configurations as with traditional config files.
That said, I am skeptical to the use for “proper” configuration, unless extremely extensive. Looking at storage in a relational DB, it is much more flexible than the Registry, but it does share (wholly or partially) some of the above disadvantages, including that regular text tools do not have direct access.
The use for internal state, however, might even be recommendable in many cases. For instance, Firefox uses SQLite for purposes like storing the history of visited sites—of which there can be many thousands and where very quick access can be vital to support a certain functionality, e.g. to display a real-time history suggestion when the user begins to type an address in the address bar. Similarly, a visited site might have attributes, e.g. time of last visit, that are searched for or used as sort criteria at some point. However, the sometime abuse of config files for such data does not change the fact that they are not truly configuration.
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.