Linux, OpenBSD, Windows Server Comparison: The Widows Registry Is a Technical Disaster

• Limited Registry Tools
• Registry Security and Installs

When Microsoft replaced .INI text configuration files with the registry, it made one of the worst technical decisions ever. Moving parts of the registry to Windows 2000's Active Directory does not significantly change anything. The mechanics of access may have changed, but the logical issues are pretty much the same.

I won't try to guess how Microsoft justified the adoption of a registry. I can only see one superficial appeal to it. A number of programs share configuration data and by having a central repository, they only need to go to one place to get the data. The fallacy is that registry data is accessed by key name. There is little fundamental difference between accessing a dozen different keys in a deeply nested registry tree than there is a dozen text files in different directories with different filenames. If you don't already know the key, i.e., have it stored somewhere, there is no more direct way to it than a text file whose location you don't know.

Theoretically many binary lookups should be more efficient than many file opens. In practice few applications will need to open more than two files: one containing common system data and one application specific data. Numerous binary tree lookups, in a large deeply nested structure, become quite resource intensive. This is confirmed by the fact that Windows systems slow with age as software is added; UNIX systems do not slow with age due to software installs. Further, if the directory structure is logical, you can often find the text configuration file you need, without knowing before hand what its named or where it's located. Without an exact key fragment or data, this is not possible in the registry.

A major difference between the registry and text configuration files, is that the registry is a proprietary binary format with only two widely available. general purpose utilities, for it and a number of custom GUI front ends, each of which accesses specific limited sections of the registry. There are more utilities and tools to manipulate text files than any other storage format on earth. There isn't anything that can't be done, either manually or automatically, with scripting in the way of locating, comparing or changing text files using general purpose text editing and manipulation utilities. Text files can have user friendly, graphical front ends more easily than proprietary binary files. Text file formats normally allow as much internal documentation as the developers care to provide.

The .INI format used in pre Windows 95 versions, had named areas or stanzas with an open ended number of key value pairs following. Add intelligent file names to a logical directory structure and there isn't any data that can't be stored and in a logical relationship to the programs that use the data. Even binary data can be stored in a hex representation. If the configuration data is program specific, it can go with the program. If it's system wide, it can be stored in a standard system directory, in which key filenames and stanzas within files would be reserved.

With files, programs read what they need and not much more, if the files are well planned. The SOFTWARE part of the registry on my workstation is over 8MB and I know of a SAM over 19MB. The registry grows over the life of system and systems get slower as a result, because on Windows systems, virtually all programs need to access the registry. Few if any uninstall programs, cleanup everything that was installed. When an application lacks an uninstall program or either the install or uninstall program has a bug, there is a increased chance some or all the registry entries will get left behind.

Limited Registry Tools

Microsoft provides tools to maintain only parts of the registry. IIS 3 was a good example where there were many more registry entries than there were options in the Internet Manager. It also provides two limited editors as the only general purpose access to the registry and says it's can't be responsible if these tools are used, even though they are often the only way to maintain parts of the registry. There are some additional tools in the Resource kit but their value is limited. If a registry key contains spaces, and many do, the limitations of the command line interface may provide no way to pass the necessary arguments to the utility. Correctly passing the arguments may require the equivalent of nested or escaped quotes which the NT command prompt can't do.

The registry has no equivalent of create, modify or access times so it's not possible to locate recently changed registry entries or to relate modification times to the onset of a problem.

Keys in the registry have security permissions that are very similar to directory permissions. Anyone who has seriously tightened file and directory security, on almost any kind of server, knows that this almost invariably breaks some user's access to some applications. With files, it's generally pretty straightforward to figure out who needs update access, who needs read access and who needs no access. With the registry, since all access is programmatic, behind the scenes, and not documented, it's almost impossible to know who needs access to what let alone what level of access. I've never needed a guide to tell me how to tighten file security, but any independent attempt to tighten registry security without clear guidelines as to what should and should not be changed is very likely to lead to serious trouble. Permission changes can be at the current level or apply to sub keys. The registry is quite deep in some areas and often huge in its entirety. Changing individual entries, except to limit access to known specific keys for specific security related results won't do much and changing sub keys will make changes several levels down that you can only hope need to be the same as the parent key's permissions.

Registry Security and Installs

The worst problem with the registry is that is a single structure, to which administrators normally have full access. Most software installs need to be run as an administrator. Thus any bug in a software install program can result in corruption in almost any part of the registry. Unlike file and directory related programs, where administrators generally have a pretty good idea what will and will not be affected, there is no way to know what registry keys any install program will access deliberately or unintentionally change. I'm convinced that this is the primary source of bizarre install related results.

By definition, one of the specific functions of an install program, is to update the registry. Programmers develop install programs like any others, make mistakes, and get poor specifications. There are important differences though. The registry is probably the most system specific component on any Windows system, as every system variation is reflected in it, somewhere, thus making it one of the hardest parts to properly test. All changes are normally made with the full authority of the system.

Any misunderstanding the programmer has regarding the use of system calls related to registry updates, could result in unpredictable consequences. Whatever the programmer believes his program needs to or update will get updated except when the programmer makes a mistake. Because installs execute with administrator level access, then whatever the install program is built to do, whether it is intentional or accidental, will be done. When you install software, you are normally asked what directory to put it in, usually what program group to put it in and sometimes whether or not to create a desktop icon. You're never asked about registry updates. When you install software you implicitly trust the install programmer as well as the company that employs him or her and hopefully tests the installs well. When you install Windows software, someone else is making critical system choices for you, without your knowledge or consent.

When software is installed on UNIX and configuration files specific to that software are created or updated, as opposed to a centrally shared, system-wide registry, the programmer pretty much has to have malicious intent to damage anything but the software being installed. Also, most UNIX installs are done with scripts that the administrator can read if they wish, as opposed to binary executables, which for all practical purposes, cannot be read. Further, UNIX install programs that find missing shared libraries or other perquisite parts, inform the administrator or the missing components, but allow the administrator to locate and install the prerequisites. Windows programs that require shared functions not automatically provided with the OS, automatically provide them, in whatever version the install vendor thinks is appropriate, creating DLL hell. With the registry, any programming mistakes can cause serious unintended damage. The surprise is not that some installs go bad, but that the large majority actually work.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.