Michael Eriksson
A Swede in Germany
Home » Software development | About me Impressum Contact Sitemap

The Windows registry

Of the very many, very bad ideas in the world of software, the Windows registry is one of the worst. Among the many disadvantages (compared to config files a la Unix):

  1. 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.)

  2. 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...)

  3. 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 editing files even over the respective applications built-in preference editing (“Edit/Preferences” or similar).

  4. The saving of settings for individual applications in a CMS is made considerably harder (if not entirely impossible).

  5. 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 config default config files contain extensive comments and suggestions—as do many publicized personal config files).

  6. Damage done while editing the entries for one program can break the entire registry.

  7. The entries for the typical program is 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.

  8. 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 restraints is put upon what the user can do”: It is not hard to find further examples in this vein, e.g. several users sharing a config file on a network drive.

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.

Purported advantages:

  1. It provides a centralized mechanism for saving various settings, with no need for home-made storage formats and similar.

    This is true; however, this has nothing to do with the actual registry in it self. Providing a corresponding interface for developers that based on, e.g., traditional config files would have been less effort—without the disadvantages of the registry.

  2. 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.

    Further, the user may 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 typically 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 competitors that often have had the same or superior functionality for years (the most notable example being the DOS-to-Windows switch, where Unix, Next, Apple were all years ahead).