Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software

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 a basis for all system-wide hardware and software parameters and custom user settings that exist in Windows.

The first successful operating system from 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 the 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. At the same time, 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 didn't warn the user when the Win.ini file grew above its limit and all modifications added to the last sections of the file (out of 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 for system information related to the hardware. In contrast to the Win.ini file that stored information mainly related to system behavior, System.ini contained hardware-related data and information about device drivers, shells to load, and so on.

  • The Progman.ini file contained initialization settings for Windows Program Manager, and the Winfile.ini file contained Windows File Manager settings. If one or both of these files were missing (in contrast to the Win.ini and System.ini files), Windows could still start. However, both Windows Program Manager and Windows File Manager would then start using the standard configuration and all custom settings would be lost. As for the Control.ini file, it contained the Control Panel 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 Windows 95/98/ME and Windows NT/2000/XP registries. This was a hierarchical database that comprised a single root container structure named 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 provided the ability 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 make more than one attempt to obtain the desired result. As for 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, however, this recommendation was just producing another limitation, because it was restricting the capabilities of sharing information among applications.

The Purpose of the Registry

The registry is a successor to INI files, which had serious drawbacks and limitations and were so inconvenient to use. Windows NT 3.5 was the first operating system from the Windows family that had a registry 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 represented the centralized source of configuration information, which provided the capability of managing the system environment much more efficiently.

Windows NT/2000/XP system components that use the registry are briefly described below:

• Setup programs. Any time a setup program runs (including both Windows Setup program 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 successfully complete the installation procedure are present in the system. Because the registry is a centralized storage of configuration information, all applications can share this information and get broader capabilities of interaction with each other. Any application program claiming to have the "Designed for Windows" status has to use the registry and provide a special uninstall utility allowing the user to delete this application correctly (Fig. 1.1). 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.

  Fig. 1.1: The uninstall utility deletes registry settings that correspond to the application to be uninstalled

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

• Windows NT/2000/XP kernel. During the system boot process, Windows NT/2000/XP 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 made many enhancements to the Windows XP kernel, mainly intended 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 requests 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 it needs, including IRQ and DMA. The system then includes this data into 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. Windows NT/2000/XP administrative utilities, 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/XP supports 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, let's 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 in to the local computer for the first time; roaming user profiles, created by network administrator and stored on the server; and mandatory user profiles—these are roaming profiles, which are bound to be used. User profile information is also stored in the registry. To manage Windows 2000 user profiles, double-click System in the Control Panel window and go to the User Profiles tab. To manage user profiles in Windows XP Professional, start the System applet in Control Panel, go to the Advanced tab (Fig. 1.2), and click the Settings button in the User Profiles group to open the User Profiles window (Fig. 1.3). 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.

  Fig. 1.2: The Advanced tab of the System Properties window

  Fig. 1.3: 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, double-click System in the Control Panel window, go to the Hardware tab (Fig. 1.4) and then click the Hardware Profiles button. This will open the Hardware Profiles window shown in Fig. 1.5. Like in Windows 2000, when you install Windows XP, the Setup program creates the standard hardware profile, which includes information on all hardware devices detected at the time of installation.

  Fig. 1.4: The Hardware tab of the System Properties window

  Fig. 1.5: The Hardware Profiles window