The Windows Registry
Once upon a time (early 1997), I pondered the possibility of writing a technical book (one of those heavy ones you can buy at Borders/Barnes & Noble/Amazon, etc.). I decided not to, for a variety of reasons (one being that I couldn't just make stuff up and that makes writing a little slower...) This was my sample chapter. BTW, the Monster in the basement story shows up again in the COM and the Registry mini-lecture.
The Windows Registry is a centralized database that stores system and application configuration data, ultimately negating the need for multiple initialization (INI) and configuration files. Although constructed differently, the Registries of both Windows 9x and Windows NT share the same goals and perform like functions, providing one location for the operating system to store and check configuration information.
In the days of 16-bit development, persistent data-most recently used document lists, default fonts, file locations and all the other information usually set using Tools -> Options-was kept in INI files. In the 32-bit development world of today, Microsoft recommends developers utilize the Registry instead.
The structure of the Registry resembles the structure of the INI files. Each Registry key, a logical subtree (botanical origins of Registry terms explained a bit later) grouping, matches the bracketed INI heading, and each Registry value matches entries under the bracketed INI heading.
During an upgrade installation, the setup program will migrate information from certain INI files into the Registry. Windows NT provides a continuing way to communicate INI file information into the Registry by using the values of a key called IniFileMapping. NT uses the mappings in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping key to transfer the data sent to WIN.INI by an application's programmer into the appropriate Registry area. Any calls made to WIN.INI will be redirected into the Registry.
Most users of Windows 9x and Windows NT will note the continuing presence of INI files along with perhaps a CONFIG.SYS file. These files exist for compatibility with 16-bit Windows applications and real-mode system components. The demise of the multiple INI and configuration files will come to pass only when all applications and components are fully 32-bit.
Some of the advantages of the Registry over INI and configuration files (AUTOEXEC.BAT, CONFIG.SYS) include the following:
- The Registry is a single source of data for all system parameters. In the event of system failure, only the single Registry entity needs to be restored.
- The Registry can be configured through the use of Control Panels and structured administrative tools, reducing the likelihood of syntax errors. Someone like Dilbert's boss cannot just double-click and start editing configuration information in a text-editor environment. Windows NT's Registry can be secured, as well.
- System Administrators can examine Registries of remote computers and special system policy Registries can override local Registries.
- The operating system automatically backs up the last known good Registry used to start the computer. INI files must be backed up at the instigation of the user.
- User-specific Registry information can be stored on a central network server so that users may "rove" to any computer on the network and have access to their personal profile.
- Registry settings for multiple users can be stored on one computer.
- Whereas INI files do not support nested headings, Registry keys can contain subkeys, and thus, support a more complex data organization such as multiple sets of data.
- Registry values are more flexible: they can consist of binary as well as more human-friendly string data. Windows NT even supports multiple and expandable string data. INI files use only simple string data.
The Windows 9x Registry is composed of two hidden, read-only, system files, SYSTEM.DAT and USER.DAT, as well as dynamic information available only while the system is running. SYSTEM.DAT lives in the Windows directory and USER.DAT can live either in Windows directory, a personal Profile folder on the local machine, or a Home directory on a network server. Looking at Figure 1.5, the Registry structure looks a lot like the Explorer tree view. The tree terminology is pervasive in Registry discussions. Trees have roots at their base and divide off into many branches. The Windows 9x Registry is organized into six root keys.
These keys are always open and applications use their predefined handles (thus the H at the start of each) as entry points to other keys. HKEY_LOCAL_MACHINE and HKEY_USERS are the main keys with the others being alias branches of those two:
- HKEY_CLASSES_ROOT: Alias branch of HKEY_LOCAL_MACHINE\Software\Classes used to describe software settings and provide compatibility with the Win 3.1x registration database. The first thing you would see in here is a list of file extensions recognized by the operating system. This key will return to haunt the OLE/ActiveX chapter.
- HKEY_CURRENT_USER: Alias branch of HKEY_USERS containing current user's settings.
- HKEY_LOCAL_MACHINE: Computer-specific information about the type of hardware installed and software settings for all users who log onto the computer. Data can include device drivers, security settings, hardware profiles, and uninstall details. Information kept here is specific to the computer, regardless of which user logs on.
- HKEY_USERS: Information about settings for all users known to the machine. Things like sound event schemes, mouse double-click speed, color schemes, and Dial-Up Networking settings are stored in here.
- HKEY_CURRENT_CONFIG: Alias branch of HKEY_LOCAL_MACHINE\Config for current hardware profile.
- HKEY_DYN_DATA: Pseudo-alias branch of HKEY_LOCAL_MACHINE for Plug and Play information. Information in here is not stored on disk inside SYSTEM.DAT. It re-creates itself at the start of each session and mutates throughout. Performance measurement and hot swapping device information can be found here.
Each time the computer successfully (in operating system's eyes, not yours) starts up, the operating system copies the SYSTEM.DAT and USER.DAT files to SYSTEM.DA0 and USER.DA0 backups. If something goes wrong later, these DA0 files can be copied over the bad DAT files. However, Windows 9x, mistakenly assuming success, has been known to copy a defective DAT over the last, best hope for your computer, yesterday's DA0.
To be entirely safe, one should regularly back up the Registry either by using the tools provided on the Windows 9x CD, or export it, in whole or in part, from the Registry Editor (Regedit.exe) as a special type of text file called a REG file. This file can be imported back in with the Registry Editor or loaded with a command line editor.
Superficially, the Windows NT Registry appears to be the same as the Windows 9x Registry, at least when using the Regedit.exe utility. Unfortunately, Regedit.exe is hard-coded to list HKEY_DYN_DATA, whether the Registry under scrutiny contains that key or not. Windows NT, lacking the full Plug and Play (Pray?) capabilities of Windows 9x, also lacks the corresponding key, HKEY_DYN_DATA. (To see a more exact picture of NT's Registry, use the more powerful Regedt32.exe tool.) Other than that, (other than that, Caesar, how was the Senate meeting?.), the Windows NT Registry has the same root keys as Windows 9x, and the same types of configuration information can be found under each main key.
The Windows NT Registry is more complex than Windows 9x's, however; instead of just two files, NT's Registry is composed of many files, organized into permanent structures called hives (so named because some guy at Microsoft, probably as a result of drinking one too many of those free cola sodas, thought the convoluted paths of the registry resembled a bee hive; go figure.). Again, HKEY_LOCAL_MACHINE and HKEY_USERS are the main keys and the hives represent their main subkeys:
- HKEY_LOCAL_MACHINE\Sam: Alias of HKEY_LOCAL_MACHINE\Security; stands for Security Account Manager, now called Directory Service Database. Stores security information for users, groups, and domains.
- HKEY_LOCAL_MACHINE\Security: Contains local security policy for user rights, passwords, and group membership. Cannot be edited through the Registry Editor; use User Manager instead.
- HKEY_LOCAL_MACHINE\Software: Contains computer specific application settings in company subkeys (such as Microsoft), as well as Windows settings.
- HKEY_LOCAL_MACHINE\System: Stores information about control sets, including device classes, hardware profiles, and system services listed in the Device Manager.
- HKEY_USERS\.Default: Contains typical user-type settings (sounds, cursors, colors), called the system default profile, that will be assigned to any user logging on for the first time, and that are used before a user has logged on (the schemes in use when you see the Ctrl+Alt+Del logon screen).
- HKEY_USERS\
(that big long number): Stores the specific user settings.
For those of you who noted the absence of HKEY_LOCAL_MACHINE\Hardware, the first subkey beneath HKEY_LOCAL_MACHINE, that data is not permanently stored on disk, but dynamically re-constructed upon each startup.
The Sam and Security hives have two files associated with them: one named for the hive itself (no extension), and the other a LOG file, which contains a log of all changes to a hive since it was created during setup. The Software and Default hives have in addition to the hive and log files, a SAV file, which contains a backup copy of the hive as it stood upon completion of the text mode portion of setup. In the event of computer failure, demonic possession, or other misfortunes, NT can rebuild the hives from their SAV and LOG files. (Since the user is not allowed to directly modify the Sam and Security hives, there is no need for them to have SAV files.) The System hive, besides the hive, LOG and SAV files, has an ALT file, which is an exact copy backup. The exact copy ALT file is needed because the System hive cannot be rebuilt from the SAV and LOG files during startup because NT sort of needs what is in the System hive to startup. Instead, System.alt is copied directly over the System hive file.
The System hive contains the information needed for the Last Known Good, or the last configuration control set known to happily boot the computer. The secret to proper use of the Last Known Good is being able to predict before logging in whether the system is okay or not. If not, invoke the Last Known Good. With Windows NT the user, not the operating system, generally makes the prediction as to what will be successful. By choosing unwisely and logging in to a bad configuration set it is possible, just as in Windows 9x, to overwrite the last known good.
The HKEY_USERS\
Windows NT Registry files should be backed up using the Repair Disk application to update the emergency repair disks, although it is possible as well to selectively save and restore key branches using the Regedt32.exe Registry Editor.
Windows NT provides security for its Registry with a Read Only Mode option for Regedt32.exe, as well as the usual NT security provisions. However, anyone with a copy of Regedit.exe can poke around Windows 9x's Registry. Microsoft recommends that no one edit the Registry directly (look, but don't touch) and eschews all technical support responsibility for hand-edited Registries. Should you obtain access to your Registry, remember that there is no undo feature in the Registry Editor. Do not think you can just close the Registry Editor without saving changes if you make a mistake. Once you make a change, it is flushed into the system. If, despite official warnings, you choose to forge onward, and, say, modify your Recycle Bin's verb list to allow renaming, make sure that you have a backup copy in case something goes awry.
Many developers view the Windows Registry as the monster in the basement. Every time I tell my students in a Visual Basic class to "Start, Run, Regedit," for some that is analogous to hearing one's mom say "Run down to the basement and get a can of creamed corn." The careful creep down the steps, the rush into the pantry, the frantic can grab, the frenzied dash back up the steps, monster closely following. (Ah, the memories..) For the programmer, the can of creamed corn is often a listing of a class server in HKEY_CLASSES_ROOT, and that click in the upper right hand corner is the wild flight back to the kitchen. It does not have to be that way. Some of us eventually ended up with rooms in the basement (the monster moved outside behind the tool shed). Properly understood, and approached with the sort of respect one gives strange animals, the Registry is an important information repository for developers. We will deal with it more in the next chapter's discussion of OLE and ActiveX.
Alrak's Course Resources ©2002-2022 Karla Carter. All rights reserved. This material (including, but not limited to, Mini-lectures and Challenge Labs) may not be reproduced, displayed, modified or distributed without the express prior written permission of the copyright holder. For permission, contact Karla.