The mysterious Windows registry

It seemed like a good idea at the time, and perhaps it was. Microsoft created the Windows registry, a hierarchical database of configuration information, to end the stampede of .INI files from ISVs and Microsoft itself, and to create a better way to configure systems and applications.

In some ways it's an undeniable success: The registry makes it easy to separate user-specific information from system-wide information, and it puts all of the system configuration information in one place. But thanks to the steady accumulation of data items over the years relating to various hardware and software products, the standard registry in Windows 2000 has become so large that Microsoft has begun recommending that developers put larger (greater than 2KB) items in separate files in certain locations rather than in registry items. In other words, the system configuration information is no longer all in one place.

So large is even the smallest registry that a Windows 2000 emergency rescue diskette can no longer hold enough system information to rescue many failed systems. (Microsoft addressed this problem by adding the boot-time recovery console, but that software has its own limitations.)

As bad as the registry's bloat can be, disorganization is a bigger problem. The official public documentation of the registry is in the regentry.chm file in the Windows 2000 Server Resource Kit. Even a casual perusal of this file compared to a default registry shows that huge swaths of the actual registry aren't documented. According to Kathy Ivens, author of "ADMIN911: Windows 2000 Registry" (Osborne/McGraw-Hill, December 2000), a bare 20 percent of the registry is documented.

The absence of documentation leads to all kinds of problems, many of which come back to bite Microsoft's technical support staff. The Web is filled with sites that offer dangerous registry tips written by people who don't quite know what they're doing. A technique that worked on their system won't necessarily work on yours. Absent an official definition, who's to know why?

And even a casual analysis of the sections on Microsoft's own software in the registry shows that they have no rules for where and how they create and name keys and data items. As a result, Microsoft developers create redundant entries all over the registry.

Even worse is an effect known to registry insiders as tattooing, where a single system characteristic — such as whether a particular menu item on the Start Menu is displayed — can be controlled by multiple registry entries. According to Ivens, the people who thought up group policies in Windows 2000 had the good sense to standardize locations for policy settings. But there's still a tattooing problem, as many policies control characteristics that are also controlled by pre-Windows 2000 registry structures. There's supposed to be a pecking order that determines which registry item controls a setting, but Ivens says it doesn't always work.

In addition, the registry has bugs that cause system problems, as anyone who has called Microsoft support and been given a registry change can attest. At one level these are simply bugs that Microsoft will probably fix over time, but they're symptomatic of a larger problem: nobody's setting and enforcing rules for how the registry is used.

Ivens thinks it's too late to fix the registry, because too much code from Microsoft and elsewhere relies on existing structures. But if things are to get better instead of worse, Microsoft must standardize its registry use and behavior, and must document what's already there.

Larry Seltzer is a freelance writer and software developer and the author of "ADMIN911:Windows 2000 Terminal Services." He can be reached at larry@larryseltzer.com.