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
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
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
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.
ote 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.
Windows Server 2003 system components that use the registry (Fig. 1.1) are briefly described
Figure 1.1: Windows Server 2003 system components that use the registry
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.
Figure 1.2: The uninstall utility deletes registry settings that correspond to the application
to be uninstalled
- 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
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 (Fig. 1.3), and click on the
Settings button in the User Profiles group to open the User Profiles window (Fig. 1.4).
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.
Figure 1.3: The Advanced tab of the System Properties window
- Figure 1.4: The User Profiles window
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 (Fig. 1.5)
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
- Figure 1.5: The Hardware tab of the System Properties window
Figure 1.6: The Hardware Profiles window
- 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.