1.1 A Brief History of the Registry

Before I plunge into the nuts and bolts of working with the Registry, let me set the stage by explaining how the Registry gained its starring role in Windows 2000. Besides being good preparation for amazing your friends with computer-industry trivia, the Registry's path to fame illustrates some of its strengths and weaknesses.

In the beginning, of course, there was no Registry. MS-DOS applications were responsible for storing their own persistent settings in configuration files. The operating system had its own set of configuration files; the most famous of these files are config.sys andautoexec.bat, which control hardware and operating system settings.

At first blush, this approach may seem reasonable. After all, applications' settings are generally private, and they don't usually affect other programs. Most components of MS-DOS itself weren't configurable anyway, so there was little need (or demand) for a better configuration mechanism. If the configuration data for a single application was lost or corrupted, restoring it was reasonably simple and could be done without affecting anything else on the computer.

1.1.1 Windows 3.0

Windows 3.0 improved on the MS-DOS approach by introducing the idea of a single, systemwide set of operating-system preference and settings data. In addition to DOS' configuration files, Windows 3.0 itself added four initialization files ( progman.ini, control.ini, win.ini, and system.ini ) that contained information about the system's hardware configuration, device drivers, and application settings. These files quickly became known as INI files, after their extension.

Microsoft chose a simple, human-readable ASCII format for INI files; not only did this ease the task of writing programs to use these files, but it also made it possible for end users to inspect and change their contents. One of the important features Microsoft wanted to deliver in Windows 3.0 was Macintosh-like customization; users wanted to be able to set their own color schemes, fonts, desktop backgrounds, and so on. By default, the Windows File Manager included a file mapping so that double-clicking an INI file would open it in the Notepad text editor, as shown in Figure 1.1.

Figure 1.1. Simple INI file

In addition to storing Windows' settings in INI files, Microsoft provided a set of API routines (often called the private profile API ) that gave programmers a way to create their own initialization files. The theory was that application programmers could use INI files to store private settings that were specific to their applications. Settings that could be useful to several applications--for example, lists of which fonts were installed on a computer--lived in the system's INI files, while application-specific settings were in the application's private INI files. Application programmers enthusiastically embraced this idea, and before long most applications used INI files for their private settings.

However, INI files weren't perfect; in fact, they suffered from some fairly serious weaknesses:

They were easily editable

An old quote from the Unix fortune program says that you can make software foolproof, but you can't make it damn-fool proof. INI files quickly provided a concrete example of this old saw; because INI files were editable, users felt free to edit them. This flexibility did make it easy for users to customize their environments or make necessary changes; it also made it much easier for a user to break a single application, an entire service (such as printing or file sharing), or Windows itself by making an accidental or ill-informed change to an INI file.

They were easy to break

INI files provided a one-time link between a program and its settings; they weren't dynamic enough to reflect changes in the machine's configuration or environment. For example, many presentation graphics programs built a list of available fonts during their installation process. If you later added—or, worse, remov—fonts, the presentation package might or might not notice the changes, meaning either that you couldn't use newly installed fonts or the package could crash while trying to use fonts the application thought were still available. This lack of flexibility was partly due to the fact that Windows didn't have any way to be notified when something on the computer was changed; without these alerts, there was no way to tell when INI file data needed to be updated.

They led to Balkanization

Microsoft didn't provide any explicit guidelines as to where INI files should be stored or what should go in them; in the absence of these rules, application programmers felt free to put INI files in various locations. Some used the Windows directory itself, while others stored their INI files in the same directory as the application or in some other seemingly logical location. To compound the problem, some applications put their private data directly into win.ini, while others kept their own private copies of such things as font lists and printer settings that were explicitly supposed to be shared between applications.

They had implementation limits

INI files had to be smaller than 64 KB in length; in addition, the Windows profile API calls blissfully ignores all but the first instance of settings with the same name within one section of the file. An even more serious limit was that INI files were inseparably bound to the original PC concept of "one user, one machine"; there was no way to easily move settings around so that users who needed to use different computers could keep their preferred settings.

1.1.2 The First Registry: Windows 3.1

Windows 3.1 added several new features that improved interapplication integration and ease of use. Chief among them were two new technologies, Object Linking and Embedding (OLE) and drag and drop. Both features required an up-to-date, correct database of program locations and capabilities. For example, object embedding could only work if the source and destination applications had some way to communicate exactly what type of data was being embedded, and the File Manager required access to a database of mappings to associate files with the applications that created them.

To provide this information, Windows 3.1 included the first Windows registration database, which quickly became known as the Registry. This Registry offered solutions to several of the problems posed by INI files:

The Registry provided a single place to store data

Instead of segregating data into separate INI files, both system and application-specific configuration data could be stored in the Registry. In the original Windows 3.1 implementation, all Registry data was stored in a single file named reg.dat. Keeping system and application settings in one place reduced both the number and complexity of INI files; in addition, having a one-stop system for storing preferences and setting data made it possible to better share information such as font lists between different applications.

The Registry wasn't as easy to edit

INI files were plain text, so it was easy to edit them. This was both a blessing and a curse; users could make changes when necessary, but they were often prone to making unnecessary or instability-causing changes. The data in reg.dat was stored using an undocumented binary format, and the only way users could edit it was with the Windows 3.1 Registry editor. Windows 3.1 also introduced the first version of the Registry access API, thus making it possible for programmers to read and write Registry data directly from their programs.

The Registry had a clearly defined hierarchical structure

The structure of INI files was haphazard at best: sections could appear in any order within the file, and values could appear anywhere in the section. There was no good way to group related settings, especially when they might appear in different files!

However, the Windows 3.1 Registry still wasn't perfect. It supported only a single hierarchy for storing all system and application settings, and the reg.dat file was still subject to the 64-KB size limitation that hampered INI files. In addition, Windows 3.1 itself didn't improve on the problem of synchronizing the Registry's contents with the state of software, fonts, and other items actually loaded on the computer, so there was no guarantee that the Registry, the INI files, and the actual software loaded on the computer would stay in synch. Finally, the Windows 3.1 Registry didn't offer any solution to the problem of allowing users' settings to move with them to different computers on a network, or even allowing more than one user to keep settings on a single machine.

Despite these shortcomings, the Windows 3.1 Registry introduced several features that carried over to its successors. First and foremost is the concept of the Registry's hierarchy, which looks much like the structure of a Windows directory tree. In a filesystem, the topmost item is a root directory, which can contain any number of files and folders. Each folder can in turn contain nested subfolders or files, and you can uniquely identify any object on the disk by constructing a full pathname that points to it; for example, c:\users\paul\proposal.doc and c:\program files\eudora\attach\proposal.doc are different files, even though they share the same name. The topmost item in the Registry's structure (corresponding to a root directory in a filesystem) is a root key . All other keys in the Registry are children of one of the root keys (although Windows 3.1 supported only one root key, named HKEY_CLASSES_ROOT). Each key can contain either values (the Registry equivalent of a data file) or nestedsubkeys , equivalent to nested folders. Just as with files and folders, you can uniquely identify a Registry key by building a full path to it.

In addition to providing a hierarchy for keys, the Windows 3.1 Registry introduced the idea that keys have names and values. The key's name (for example, DisableServerThread) can be combined with the full path to the key to identify it (as in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print\DisableServerThread). The value of the key holds whatever data belongs to the key; the actual contents vary from key to key.

1.1.3 Windows NT 3.1, 3.5, and 3.51

Windows NT was introduced in 1993 as Microsoft's industrial-strength operating system. It was expressly designed to compete with Unix workstations and servers; since these machines easily supported multiple users who could take turns using a single computer, shared workspaces, and networkwide configuration sharing, Microsoft decided that NT needed to do all these as well. To accomplish these goals, NT required a more flexible and capable Registry than that in Windows 3.1, so they kept the basic concepts but changed both the implementation and capabilities to match NT's requirements.

As noted before, the NT Registry is key to everything NT does: from the time the machine boots until you shut it down, applications, drivers, and services depend on the data they get from the Registry to do their jobs. Since the Registry was going to be ubiquitous, some implementation changes were needed. First to go was the old 64-KB limit; NT Registry files can grow as large as needed. Instead of using a single file, NT's Registry data is split into a number of files, but they all appear as a single set of keys. To handle the wider variety of data required to support the new system components and features, Microsoft split the single hierarchy of the Windows 3.1 Registry into several root keys (see Chapter 2, for details on these keys). In addition, a great deal of effort went into optimizing the Registry-handling code to keep Registry performance from being a systemwide bottleneck.

The operating system's underlying security model could easily take up a book on its own, but I'll boil it down to its bare essence: every object in a Windows 2000 machine has a unique security ID, is owned by someone, and can have its own access control list (ACL) that determines who can read, modify, and remove the object. Most system resources--files, devices, the Win32 subsystem, and Registry keys, for example--are objects that have unique identifiers; this identifier may have a security identifier attached to it or not, depending on the type of object. The Registry itself is an object, as are all its keys; this means that each root key or subkey can have an ACL associated with it, so it's possible to grant very fine-grained control over which users and system components can read and modify keys. This security model continues in Windows 2000, by the way.

Another key feature of Windows NT was its ability to allow multiple users to share a single computer, with complete security partitioning between files and objects belonging to different users. The Security Reference Monitor, which is charged with enforcing that partitioning, depends on the presence of object-specific security access tokens bound to these objects.

NT also provided tools that could remotely access the Registry on one computer from another; for example, a system administrator could use his machine to view and modify the Registry on any machine to which he had administrator access. This made it easier for administrators to troubleshoot and fix Registry-related problems, since they could often make an initial diagnosis without leaving their desks.

Microsoft encouraged developers writing NT software to use the Registry instead of INI files. They set a fairly good example by making most NT system components and applications use the Registry themselves; as an added incentive, they provided a special facility that lets older Windows 3.x programs use the Registry instead of an INI file automatically by creating a copy of the INI file in the Registry.

To top off these changes, the original version of NT included a brand-new, 32-bit Registry editor, RegEdt32 (see Figure 1.2). Each root key appears in its own child window; in addition to showing keys in a familiar tree format, RegEdt32 adds commands for connecting to remote computers' registries, viewing and changing access controls on keys, and exporting and importing Registry entries. (All these commands are explained in Chapter 5.)

Figure 1.2. RegEdt32, the NT Registry editor

NT 3.5 and 3.51 didn't make any fundamental changes to the Registry's implementation or behavior; they did, however, add new keys to the Registry to support new features. Different versions of NT have different sets of Registry keys; for example, some keys that were part of the 3.51 Registry aren't in 4.0; conversely, 4.0 adds a number of new keys that weren't present (and won't be recognized by) NT 3.51.

1.1.4 Windows 95 and 98

Windows 95 introduced a new interface to the Windows world; as it turns out, many of these interface changes, and the underlying Registry keys, made it into Windows NT 4.0. There are a number of architectural similarities between the Windows NT 3.51 and Windows 95/98 Registries. Both support multiple root keys, and both store their data in several different files instead of Windows 3.1's single file. The Win9x Registry is also tightly integrated with--and heavily used by--all components of the OS. However, the underlying implementation is very different between the two; in fact, there's no Microsoft-supported way to migrate data between the two operating systems' Registries or share data between them. The basic ideas remain the same, though. Win95 has the same set of root keys from NT 3.51, plus two new ones: HKEY_CURRENT_CONFIG and HKEY_DYN_DATA. The overall organization of the two Registries is similar. The Win95 Registry doesn't support NT-style security (though you can enable remote access), but it does support hardware and user profiles in much the same way. See Inside the Windows 95 Registry, by Ron Petrusha (O'Reilly & Associates) for a complete dissertation on the guts of Win95's Registry implementation.

1.1.5 Windows NT 4.0

NT 4.0 combined the underpinnings of NT 3.51 with the Win95 user interface; given this heritage, it's not surprising that NT 4.0 has a large number of Registry keys with names identical to Win95 keys. The primary Registry-related change between NT 4.0 and its predecessors was the addition of two new root Registry keys. In NT 4.0, a single machine may have several hardware profiles that reflect different configurations; for example, a laptop computer running NT might have one profile that includes drivers for devices in a docking station (for use when it's docked) and another, with different drivers, for when it's on the road. HKEY_CURRENT_CONFIG provides access to the current hardware and driver configuration, but what's in that configuration depends on which hardware profile the user chooses during the boot process. HKEY_CURRENT_CONFIG was included in NT 4.0 so that Win95 applications that use it would be able to run under NT 4.0. HKEY_PERFORMANCE_DATA provides a root key for information that's generated on demand, such as Performance Monitor counter data. This dynamic data isn't stored in the Registry, but applications can access it locally or remotely by using the standard Registry API calls.

In addition to these changes, NT 4.0 fully integrated the Win95 concept of system policies. These policies control what users may and may not do on their machines; for example, a policy can specify that users can't use the Run command in the Start menu and that they can't move icons around on the desktop. These policies can apply to individual users or computers, members of defined groups, or all machines or users in an NT domain, and they can be applied against the user's settings or against the machine's settings in HKEY_LOCAL_MACHINE. In Windows NT, policies are actually implemented as Registry settings; the System Policy Editor (shown in Figure 1.3) provides a friendlier (and safer!) alternative to the Registry editor for building and distributing system policies to one or many computers in a domain or workgroup.

Figure 1.3. SPE for managing small- or large-scale policies

1.1.6 Windows 2000

Windows 2000 was originally called Windows NT 5.0. Given that fact (which Microsoft is trying hard to obscure), perhaps it's not surprising that not much in the Registry is different between NT 4.0 and Windows 2000. Early rumors said that the metabase, used by the Internet Information Server (IIS) product family, would supplant the Registry in Windows 2000, but neither the metabase nor the Active Directory have completely replaced the Registry. The Windows NT Registry editors survive virtually unchanged, as do the application programming interfaces programs use to read and write Registry data (though there are some new additions and extensions). There are a number of internal changes to the HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT hives, and a number of Windows NT 4.0 keys have been moved or superseded.

The system facilities that use the Registry, however, are another matter. The NT 4.0 System Policy Editor is still present, but it's been largely replaced by Windows 2000's support for group policy objects (GPOs; discussed in more detail in Chapter 7). GPOs store their settings in the Active Directory, though settings in a policy may actually be applied to the user or computer portions of the target computer's Registry.