| he registry contains a wealth of information for programmers and power users. An understanding of the registry can help developers better integrate their applications with the system software. By editing the registry, power users can customize the behavior of applications in ways that are not possible with preference dialogs and snap-ins alone. In this article I'll discuss the keys and registry features found in WindowsÂ® 2000, along with some new powerful API functions for accessing registry data.
The original goal of the registryâ€"the systemwide data repositoryâ€"was to replace INI files that were used in the early days of Windows to store user and application configuration data.
There were several good reasons to replace INI files. First of all, they are text-based and easily edited in a text editor. As such, they are subject to unauthorized access and easy tampering. Additionally, information that needed to be stored in a structured, hierarchical way was saved as flat text in an INI file. XML would have been a good way to combine the usability of INI files with a rather complex data description, but XML had not been developed five years ago. Third, INI files force a decentralization of information. Without clear and fixed rules for organizing documents and folders, there is a risk that valuable information will get lost, duplicated, corrupted, or simply become more difficult to retrieve.
Furthermore, INI files impose size restrictions; you cannot store more than 64KB of data in a single entry. This limitation is not due to the INI file itself, but to the API functions that read and return the values from the file. Unless you want to write your own version of functions like GetPrivateProfileString, bear in mind that these functions can't address buffers larger than 64KB.
In contrast to all this, the registry is subject to security policies and can be manipulated only through special tools (like the Registry Editor) and API functions. Such a programming interface shields developers from having to change their code should Microsoft modify the internal registry structure.
Figure 1Registry Size Information
Size restrictions are not a problem in the Windows registry, even though its size isn't unlimited. Figure 1 shows the system dialog that allows you to see the current size of the registry and change the maximum amount of space it can use. This dialog box appears when you right-click on My Computer, select Properties, select the Advanced Tab, open the Performance Options dialog, and then click the Change button to change the current settings. This option is only available in Windows NTÂ® and Windows 2000, and only if you log in with administrator privileges. I'll say more about registry size later in this article.
The Windows 9x registry is completely different from the Windows 2000 version, but the Windows 2000 registry underwent only minor changes from Windows NT 4.0. In Windows 9x, the registry consists of two files, system.dat and user.dat, in the Windows folder. System.dat contains information about the local machine and the software installed there; user.dat contains user-specific information for both applications and the machine.
Upon installation, the operating system also creates a system.1st file in the root directory of the C drive. This file is a snapshot of the registry taken at the moment that Windows is correctly installed, but before you start using the system. You can rely on that file to be an early backup copy of the registry. In case of serious registry damage, the existing system.dat file can be replaced with system.1st, and all applications can be reinstalled. The Knowledge Base article Q131431 describes troubleshooting the registry in more detail. Actually, system.1st is not necessary for the proper operation of Windows, so you could delete it. However, this file should be saved as a backup of the registry. In Windows 2000, all these files disappeared, but the programming interface for the registry is still the same.
Backup and Restore
Windows 98 automatically backs up the registry during startup. A utility called scanregw.exe checks the registry status, and if all is working properly, performs a backup. However, you can run the utility at any time in order to make your own backup.
The windows\sysbckup folder contains up to five RBxxx.cab files; these are the five most recent backups. xxx represents the ordinal number of the backup. The cabinet file contains four files: system.dat, user.dat, win.ini, and system.ini.
While the CAB format can save disk space, it is not a file format you can use to restore the registry directly. In fact, to replace the registry files you need to start Windows in safe command prompt only mode (essentially, MS-DOSÂ® mode). When you start Windows in safe command prompt mode, the registry files aren't in use, so you can replace the registry with the contents of these CAB files. However, you might not be able to extract the contents of a CAB file because you need a special tool to process CAB files in MS-DOS mode. So, before you attempt to restore a backup copy, make sure you extract the files from the CAB file while Windows is running and put them into a different folder. Then reenter safe command prompt only mode and replace the registry files with MS-DOS commands.
In Windows 2000 there is no automatic backup feature. However, you can implement backups in another way. The registry backup is built into the Windows 2000 Backup utility, which you can find in Programs | Accessories | System Tools. From the main page of the Backup utility, click on the Emergency Repair Disk (ERD) button and make sure to check the proper option for backing up registry files, as shown in Figure 2.
Figure 2Registry Backup in Windows 2000
The procedure doesn't even attempt to copy the current registry to a floppyâ€"an impossible operation since the average size of the registry on many machines is close to 20MB. Instead, the backup procedure makes a copy of the registry files in the system repair folder: c:\winnt\repair. All the information stored in this folder is necessary to repair a damaged Windows 2000 installation and shouldn't be deleted or modified. In particular, the latest registry backup is saved in the RegBack subfolder.
To restore correct registry information, you should run the Restore Wizard from the Backup utility and follow its instructions. Use the previously created ERD if you cannot start and log on to Windows. Through the Backup utility, you can also schedule the registry backup at predetermined intervals.
For the Windows 2000 Backup tool, the system state includes at least the registry, the COM+ Class Registration database, and the system boot files. It also includes the Certificate Services database if the server is operating as a certificate server. If it is acting as a domain controller, then the directory services database is automatically part of the backup. For more information about the system state backup and restore under Windows NT 4.0 and earlier, refer to the Knowledge Base articles Q129037 and Q126464.
The standard backup procedures copy all the registry files. To back up small portions of the registry, such as a node or a subtree, you can use the Export Registry File menu command of the Registry Editor (regedit). It allows you to select the branch to save and creates a text file with a REG extension. A REG file can also be used to enter registry settings later. The Import/Export Registry Editor feature is another option for backing up small branches of the registry before you test potentially harmful code.
Viewing Registry Data
The programmer's window into the system registry, the Registry Editor, is shown in Figure 3. It is a collection of root nodes containing different types of information. Each node expands into a number of subnodes or keys. All nodes can have any number of named entries and exactly one unnamed entryâ€"often referred to as the default entry. An entry is a name-value pair. Each entry can have a type chosen from a collection of possible types.
The most important types are those listed in Figure 4. Notice that a REG_MULTI_SZ entry can be created only through the API functions, while a REG_EXPAND_SZ entry can also be created through the Windows Script Host object model. Only binary, text, and numeric entries can be created through visual tools such as the Registry Editor. You access a specific key or entry through a path name that identifies a logical path from one root node to the actual leaf.
Both the Registry Editor and the Win32Â® Registry API provide a sort of virtualization of the registry content. The root nodes, keys, and entries you see represented don't correspond exactly to the actual files that make up the Windows 2000 registry. The structure of these component files is significantly different from the tree you usually see in visual editors and API functions. For example, neither the HKEY_CLASSES_ROOT (HKCR) nor the HKEY_CURRENT_USER (HKCU) nodes have a physical counterpart in any of the registry files. The information they show through the API virtualization is mirrored from a subtree of the HKEY_LOCAL_MACHINE (HKLM) and the HKEY_USERS (HKU) node respectively. In other words, HKCR and HKCU are aliases for HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_USERS\.default.
This also explains why in Windows 9x there are only two files: system.dat and user.dat. Their content corresponds to HKLM and HKU, which covers all the information accessible by the API and the Registry Editor.
The virtual view provided by the Win32 API makes it possible for developers to work with different registries using the same tools even though the Windows 9x and Windows 2000 registries are structurally different.
Figure 5File-type Variety
All the files that form the Windows 2000 registry are stored in the \system32\config directory. If you look at the actual contents of the folder (see Figure 5), you can see several files with different extensions. Files without extensions contain the actual data for a root node. The content of the various registry root nodes are also known as hives (see Figure 6).
Files with a .sav extension contain a copy of the specific registry node data that exists at the end of the text-mode setup stage. During the Windows 2000 startup you can distinguish two distinct stages: the text-mode stage and the graphics stage. When the system is about to leave the text-mode procedure, it saves the hives to the respective .sav files. If problems occur during the next graphic-mode step, the system restarts, but it doesn't repeat the whole setup procedure. It skips the text-mode step and reads the content of the registry hives from the respective .sav files.
Files with the .log extension contain a transaction log of all the changes to the keys and value entries in the hive. Despite the extension that might make you think this is a text file, the content of the .log files is binary.
The registry folder also contains one file with an extension of .alt. This .alt file is a backup copy of the most critical data in the HKLM hive. Windows 2000 utilizes only one ALT file, system.alt, which is a safety backup copy of the HKLM\System node.
Figure 7 shows how the hives that are visible from the Registry Editor map to physical files.
In the registry folder (\system32\config) you won't find a file that appears to contain user information. The content of HKCU and the content of the hives for other users are stored in different folders. In particular, you'll find files called ntuser.dat and ntuser.log.dat in user-specific folders under C:\Documents and Settings. For example, the HKCU settings for the Administrator can be found under C:\Documents and Settings\Administrator.
As mentioned earlier, there's an upper limit for the registry size because Windows NT and Windows 2000 stores the registry data in the paged poolâ€"a memory area available to all system components. Given this, greedy or buggy applications can fill up the registry and significantly reduce the amount of memory available to all processes. The paged pool memory has a predefined maximum size that can be manually read from and written to the PagedPoolSize entry under: