History of the Registry

The registry concept itself isn't new to Windows. However, the modern registry is an impressive advance in improving system manageability from a single source-the registry database. This database was developed as the basis for all system-wide hardware and software parameters and custom user settings that exist in Windows.

The first successful operating system in the Windows family was Microsoft Windows 3.1. This system had three different types of configuration files:

System initialization files. The standard Windows 3.1x installation had six system initialization files: Control.ini, Progman.ini, Protocol.ini, System.ini, Win.ini, and Winfile.ini. The Win.ini file contained basic information concerning software configuration, as well as some parameters that were added by applications as the user installed additional programs. In earlier Windows versions, each newly installed application introduced its settings to the Win.ini file. Thus, the file grew rapidly if the user installed a large number of applications. However, the file was limited in size (no more than 64 K). This limitation began causing problems when the file size reached its upper limit. Windows 3.1x did not warn the user when the Win.ini file grew beyond this limit and all modifications added to the last sections of the file (beyond the initialization range) were ignored by the system. Because of this, Microsoft recommended that software developers store application-specific information in separate files-so-called private initialization files (private INI files). The System.ini file served as the main storage place for system information related to hardware. The Progman.ini file contained initialization settings for Windows Program Manager and the Winfile.ini file contained Windows File Manager settings. The Protocol.ini file was added with the release of the Windows for Workgroups 3.1x operating system. This file stored initialization settings for Windows networks.

Private initialization files. These were INI files added by applications that were installed in the system. The files were used for storing application-specific information, including the size and position of application windows and lists of recently used files (the MRUList parameter).

Finally, there was the Reg.dat file, which was the direct predecessor of the Windows 9x/ME, Windows NT/2000/XP and Windows Server 2003 registries. This was a hierarchical database that comprised a single-root container structure called HKEY_CLASSES_ROOT. This root structure contained nested structures, which stored the system information needed to support OLE (Object Linking and Embedding) and file associations. This registry database allowed Windows 3.1x users to modify the behavior of linked or embedded objects and allowed them to view the list of applications registered in the Windows environment.

In contrast to INI files, which were ASCII text files available for editing by any text editor or word processor, the Reg.dat file was a binary file. To edit this file, the user needed a special application called Registry Editor (Regedit.exe). When the user started the REGEDIT.EXE /v command, this application displayed the Reg.dat file as a hierarchical structure with nested parameters. However, the structure of Reg.dat was far simpler than the structures of the modern registry.

Drawbacks of INI Files
One of the most significant problems related to INI files was their manageability. The standard set of INI files, created during the installation of Windows 3.x, didn't present any difficulties. However, as the user installed and deleted applications, the number of INI files constantly grew. This approach had some serious drawbacks:

Editing INI files manually and setting correct values for various application-specific parameters wasn't very difficult for advanced users. However, even experienced users sometimes had to try more than once to obtain the desired result. With regard to beginners, these tasks were sometimes far beyond the scope of their skills and knowledge.

Clear rules for storing INI files didn't exist. Private initialization files could be stored in any directory; they weren't write-protected, and there was always the chance of deletion. As a result, users frequently had to search for the INI files they needed and sometimes these files were hard to find.

INI files didn't provide any support for a multi-user environment. Consequently, the users couldn't customize the settings for computer systems and applications.

INI files didn't support multiple hardware configurations. Because of this, there was no Plug and Play support in Windows 3.x.

Each application stored its settings in its own private initialization file. This, of course, was an official recommendation issued by Microsoft and was intended to provide a workaround for the Win.ini size limitation mentioned earlier. On the other hand, this recommendation just produced another limitation, because it restricted the capabilities for sharing information among applications.

Note: Any Windows-compatible application (this is true for both Windows 9x/ME, Windows NT/2000, Windows XP and Windows Server 2003) has to meet a set of requirements, one of the most important being the presence of uninstall capabilities. Automatic uninstall capabilities that allow the user to delete an application correctly aren't new. However, implementation of this concept in Windows 3.x was far from easy. Modern operating systems that belong to the Windows family store all configuration data in the registry, which makes implementation of uninstall capabilities an easy task.


The Purpose of the Registry
The registry is a successor to INI files, which had serious drawbacks and limitations and, as a result, were so inconvenient to use. Windows NT 3.5 was the first operating system from the Windows family that had a registry that was more or less similar to the modern one (at that time, the registry had 4 root keys: HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CLASSES_ROOT, and HKEY_USERS). The new component of the operating system took the form of a centralized source of configuration information, which provided the possibility of managing the system environment much more efficiently.

Setup programs. Any time a setup program runs (including Windows Setup program, Windows Installer, and other setup utilities that install software or device drivers), it adds new configuration data to the registry. If the Setup program is developed correctly, it reads the registry information to determine if all the components necessary to complete the installation procedure successfully are present in the system. Because the registry is a centralized storage space for configuration information, all applications can share this information and have broader capabilities of interacting with each other. Any application program carrying the claim "Designed for Windows" has to use the registry and provide a special uninstall utility that allows the user to delete this application correctly (Fig. 1.2). Application-specific information stored in the registry allows the user to perform this procedure correctly without deleting the shared components (DLL, OCX, and so on), which may be needed by other applications.

Hardware recognizer. Each time Windows NT/2000, Windows XP, or Windows Server 2003 starts, the hardware recognizer creates a list of the devices it has detected, and stores the list in the registry. On Intel-based computers, hardware detection is performed by the hardware recognizer (Ntdetect.com) and the Windows NT/2000/XP/Server 2003 kernel (Ntoskrnl.exe).

Windows NT/2000/XP/Server 2003 kernel. During the system-boot process, the kernel reads the registry to retrieve information on the device drivers and the sequence in which they should be loaded. The Ntoskrnl.exe program also passes its own information to the registry (for example, data on the system version and build). Microsoft has introduced many enhancements to the Windows XP and Windows Server 2003 kernel, intended mainly to increase system performance and stability. As will be shown later in this chapter, these kernel enhancements also include registry enhancements (the removal of the registry size limit, for example).

PnP Manager. This new kernel-mode component was first introduced in Windows 2000. PnP Manager detects and identifies hardware devices using two identifiers: vendor identifier (Vendor ID or VID), and device identifier (device ID or DID). The combination of these two numbers uniquely identifies the device. Having detected a unique combination of VID and DID, PnP Manager asks the registry to get information about the bus where the device has been detected, and checks to see if the appropriate device driver has been installed. If the device driver hasn't been installed, PnP Manager informs the user-mode PnP subsystem. The user-mode PnP subsystem, in turn, has to detect the appropriate INF file and start the driver-installation procedure.

Device drivers. Device drivers exchange boot parameters and configuration data with the registry. This data is similar to the DEVICE= lines in the Config.sys file used to start MS-DOS. The device driver has to provide information on the system resources that it needs, including IRQ and DMA. The system then includes this data in the registry. Application programs and device drivers can read this information from the registry to provide the users with the correct installation and configuration tools.

Administrative utilities. Built-in administrative utilities supplied with Windows NT/2000, Windows XP and Windows Server 2003, including Control Panel applets and programs that belong to the Administrative Tools program group, are the most convenient and safest tools that can be used to modify the registry. Registry editors, which will be discussed in detail in Chapter 3, are special built-in utilities intended for viewing and modifying the registry. However, they should be used with care and caution.

User profiles. Windows NT/2000, Windows XP, and Windows Server 2003 support multiple user profiles. All information related to an individual user name and the user rights associated to it is stored in the registry. Chapter 10 describes user profiles in more detail. At this point, it is enough to note that the user profile defines custom display settings, networking parameters, printers, and so on. There are three types of user profiles: local user profiles, which are created automatically when the user logs on to the local computer for the first time; roaming user profiles, created by the network administrator and stored on the server; and mandatory user profiles-roaming profiles that are bound to be used. Note that, in Windows XP and Windows Server 2003, mandatory user profiles are included only for backward compatibility with the existing Windows NT 4.0 domains. User profile information is also stored in the registry. To manage Windows 2000 user profiles, double-click on System in the Control Panel window and go to the User Profiles tab. To manage user profiles in Windows XP/Windows Server 2003, start the System applet in Control Panel, go to the Advanced tab, and click on the Settings button in the User Profiles group to open the User Profiles window. You can create new user profiles here by copying existing ones. You can also delete user profiles or change their types. Note that, to perform this task, you need to log in to a local computer as the Administrator.

Hardware profiles. Unlike INI files, the registry supports multiple hardware configurations. For example, you can create hardware profiles for dock stations (this is essential for laptop users) and removable devices. Each hardware profile is a set of instructions used to specify device drivers that have to be loaded when booting the system. To create new hardware profiles in Windows XP and Windows 2003 Server, double-click on System in the Control Panel window, go to the Hardware tab and then click on Hardware Profiles button. This will open the Hardware Profiles window shown in Fig. 1.6. Like in Windows 2000, when you install Windows XP or one of the products of the Windows Server 2003 family, the Setup program creates a standard hardware profile, which includes information on all hardware devices detected at the time of installation.

Group policies. Group Policies introduced with Windows 2000 have significantly improved the ability of system and network administrators to configure security and to manage users and computers. Windows Server 2003 and Windows XP include considerable new functionality in this area. More detailed information on this topic will be provided in Chapter 10.

Remote administration tools. Windows 2000, Windows XP and Windows Server 2003 registry supports remote administration.