The Registry is a complex database of information that was built in a hierarchical fashion by the writers and programmers of Windows NT. Much like a community that is made of estates that are made of buildings that are made of walls that are made of bricks, the Registry has many components. Putting the bricks and walls and estates together differently creates a different view. Similarly, even though the Registry contains basically the same types of components on different systems, they will be brought together in a different way, creating an absolutely unique Registry.
Figure 2.1 shows the hierarchical levels of the Registry, and
the building block
nature of it.
Figure 2.1.
An organizational view of the Registry
Registry data for the computer settings and the default user settings is stored in five files in the \WINNT\SYSTEM32\CONFIG directory. (All references to the Windows NT system directory will be made as \WINNT, the default installation directory for the files. If your files are in a different location, use that directory name as a replacement for \WINNT.) Registry data for individual users in Windows NT is stored in the \WINNT\Profiles\username\NTUSER.DAT files. There is a profile and an NTUSER.DAT for every user who has logged on to that NT system. Additionally, there is a copy of that file on the Primary Domain Controller if the user is using a roaming profile. For more detail on roaming profiles, see Chapter 8, "Automatic Changes to the Registry."
The only users who have access to the Registry files are those in the Administrators or Power Users groups. Other users, although they can see the files, will not be able to edit, delete, or copy them. These files are often called the hives:
DEFAULT
SAM
SECURITY
SOFTWARE
SYSTEM
NTUSER.DAT
The other files in the CONFIG directory are auxiliary files for the Registry. Most of the auxiliary files have names that parallel the hive filenames, but with different extensions. The ones with the .LOG and .EVT extensions are event viewer files, and can be viewed with the Event Viewer. The ones with the .SAV extensions are files that were saved as part of the Last Known Good booting process (the last Registry that worked--these files won't change until your hardware changes and works correctly).
There are only two files that make up the hives in Windows 95, SYSTEM.DAT and USER.DAT.
All of the system Registry information for Windows 95 is stored in the system as SYSTEM.DAT in the Windows directory. All of the hardware settings and software information is stored in that file. It is much simpler than the NT Registry files, because there is not as much to control. Windows 95 was designed as a client to a network or as a stand-alone system, so there is not the same level of user control or security as in NT. That makes much of the work of the Registry easier, so the file is smaller.
Windows 95 Registry data for users is normally stored as USER.DAT in the Windows directory. If you set up the system through Control Panel | Passwords | User Profiles (as shown in Figure 2.2) to use more than one user profile, each user will have his own USER.DAT file stored as \WINDOWS\Profiles\username\USER.DAT. At startup, you would log on to the system, and the profile (USER.DAT information) from your directory would be loaded, maintaining your desktop and icons.
Figure 2.2. Setting up the Windows 95 user profiles.
All of the information is stored in the hives, but the Registry entries are displayed for review or editing in handle keys inside the Registry Editors. Handle keys are groupings of entries that are used to make finding and editing information easier. Because of this, the Registry is discussed in those terms here. There are six handle keys:
HKEY_LOCAL_MACHINE
HKEY_CLASSES_ROOT
HKEY_CURRENT_CONFIG
HKEY_DYN_DATA
HKEY_USERS
HKEY_CURRENT_USER
In NT 3.51 and earlier, there were only four handle keys; HKEY_CURRENT_CONFIG has been added in 95 and NT 4.0 to allow multiple hardware configurations. In Windows 95, there is yet another handle key, called HKEY_DYN_DATA, which holds all the Plug and Play information. Because NT 4.0 doesn't support Plug and Play, it does not use the HKEY_DYN_DATA handle key (even though you can see it with REGEDIT.EXE).
NT 4.0 has limited support for Plug and Play. It is limited to support for PCI devices that automatically determine their own port settings such as IRQs and I/O port addresses. NT 4.0 will not, however, override the settings of non-PCI hardware to bring it into compliance and ensure that the settings are not in conflict. NT 5.0/Cairo is supposed to implement those functions when it is released.
NOTE: The Registry in Windows NT is not compatible with the Windows 95 Registry. Upgrading from Windows 95 to Windows NT will require you to reinstall all 32-bit applications, re-create icons on the desktop, and re-create all of the user environment. This happens because, although the Registries look the same, some information is stored in different locations. This may contribute to application irregularities. Applications that work in Windows 95 may not work in NT. In order to get applications to work in NT, you will have to reinstall them (to the same directory, if desired, to save space). This also applies to Windows NT/Windows 95 dual-boot environments. Another reason the upgrade from Windows 95 to NT will not work is the difference in hardware control. The Windows 95 Plug and Play environment holds information differently than the HAL environment in NT, and the information cannot be transferred correctly. When both operating systems use a common hardware control scheme, there will be a seamless upgrade.
Handle keys simply make it easier to edit the Registry. Even though they are shown and edited as separate handle keys, HKEY_CLASSES_ROOT and HKEY_CURRENT_CONFIG are part of HKEY_LOCAL_MACHINE. (See Figure 2.3.) HKEY_CURRENT_USER is only a part of HKEY_USERS.
Figure 2.3. All Registry entries are really part of two handle keys.
HKEY_LOCAL_MACHINE includes all of HKEY_CLASSES_ROOT and HKEY_CURRENT_CONFIG.
Every time the
computer is booted, the HKEY_CURRENT_CONFIG and HKEY_CLASSES_ROOT
information is mapped and made available to view and edit.
HKEY_CLASSES_ROOT is actually HKEY_LOCAL_MACHINE\SOFTWARE\Classes,
but editing it
may be easier and less confusing in the HKEY_CLASSES_ROOT
window. HKEY_CURRENT_CONFIG\SYSTEM\
Current Control Set is the mapped information from HKEY\LOCAL_MACHINE\SYSTEM\Current
Control Set.
HKEY_USERS includes the default user information and also the user information for whoever is currently logged in. When a domain member computer is started and a user logs in, the HKEY_CURRENT_USER information is automatically pulled from the domain controller, and the HKEY_CURRENT_USER information is mapped into the system's memory. The information about the rest of the users is not sent to the system, but is retained in the domain controller.
In a workgroup or a stand-alone computer, the information comes from the local hives because there is no domain controller.
The data is further divided into keys and subkeys, creating a hierarchical (Explorer-like) structure for easier editing, as shown in Figure 2.4. Each key has grouped information and is named based on the type of data in it. Every key that has a subkey is shown with a plus (+) sign in its folder icon to indicate that there is more below it. When opened, the folder's plus sign is replaced with a minus (-) sign, and the next level of subkeys is shown.
Figure 2.4. The hierarchical structure makes it easier to find and edit necessary keys and values.
All the settings to make software,
hardware, and Windows work are in HKEY_LOCAL_MACHINE.
All of the security, user rights, and sharing information is also included in this
handle key, even though you cannot edit it here. User rights, security, and sharing
information is edited
through the Windows NT User Manager for Domains, the Explorer,
and the Windows 95 Control Panel. The keys in HKEY_LOCAL_MACHINE in Windows
NT are shown in Figure 2.5. Figure 2.6 shows the keys of HKEY_LOCAL_MACHINE
for Windows
95.
Figure 2.5.
HKEY_LOCAL_MACHINE keys in Windows NT.
Figure 2.6. HKEY_LOCAL_MACHINE keys in Windows 95.
For more detail on the individual keys, subkeys, and values contained in
HKEY_LOCAL_MACHINE,
see Appendix A, "A Closer Look at HKEY_LOCAL_MACHINE for Windows NT,"
or Appendix B, "A Closer Look at HKEY_LOCAL_MACHINE for Windows 95."
HKEY_CLASSES_ROOT contains all the information necessary to launch applications (see Figure 2.7):
Figure 2.7. HKEY_CLASSES_ROOT keys in Windows NT.
HKEY_CLASSES_ROOT in Windows 95 is shown in Figure 2.8, bearing a strong resemblance
to the one in Windows NT. Because both share most of the same applications,
the settings
are almost identical.
Figure 2.8. HKEY_CLASSES_ROOT keys in Windows 95.
For more detail on
the individual keys, subkeys, and values contained in HKEY_CLASSES_ROOT,
see Appendix C, "A Closer Look at HKEY_CLASSES_ROOT."
SOLUTIONS: If the application control functions in the Registry and the interface are the same, why are there applications that work with Windows 95 that won't work with Windows NT? Just because an application receives the "Windows 95 Compatible" logo from Microsoft, it doesn't mean that the program will also work with Windows NT. That was the original intention of Microsoft, but it turned out to be much more difficult than planned. When Microsoft determined that full compatibility would not be possible, they changed the standard, and decided that if the application was not compatible, it should at least be "graceful" in its refusal. Not all applications meet even that requirement. The biggest difference between Windows 95 and NT has to do with control of hardware by applications. Windows 95 allows it, and Windows NT doesn't. So any application that will try to control hardware directly (instead of through operating system "calls") will fail in NT. That is the primary reason fax software for 95 will not work with NT. It is also the same reason that disk utilities, time clock programs, manufacturing control applications, and many others do not work in Windows NT.
The mapping of HKEY_LOCAL_MACHINE for the current hardware configuration is in HKEY_CURRENT_CONFIG. If the system has only one configuration, the original configuration, the data will always be the same here. Creating an extra configuration in Control Panel/System/Hardware Profiles puts extra information in HKEY_LOCAL_MACHINE. With multiple configurations in Windows 95, you will be given a choice of profiles every time the computer is restarted. In Windows NT, you choose the hardware configuration in the Last Known Good menu by pressing the spacebar upon startup. Depending on which hardware profile is chosen, that specific information is mapped into HKEY_CURRENT_CONFIG. Figure 2.9 shows the HKEY_CURRENT_CONFIG keys in Windows NT, and Figure 2.10 shows the Windows 95
Figure 2.9. HKEY_CURRENT_CONFIG keys in Windows NT.
Figure 2.10. HKEY_CURRENT_CONFIG keys in Windows 95.HKEY_CURRENT_CONFIG keys.
For more detail on the individual keys, subkeys, and values contained in HKEY_CURRENT_CONFIG,
see Appendix D, "A Closer Look at
HKEY_CURRENT_CONFIG for Windows NT,"
or Appendix E, "A Closer Look at HKEY_CURRENT_CONFIG for Windows 95."
HKEY_DYN_DATA is different from all the other Registry handle keys because it does not actually get written to the hard disk drive. A Windows 95 exclusive, HKEY_DYN_DATA is the handle key that stores Plug and Play information gathered and configured at startup. It is held in RAM and used by Windows 95 for hardware control. Because it is in RAM, and not pulled from the hard disk, every time you restart your machine, it is possible for the configuration to be different. There are over 1600 potential configurations that 95 must calculate at every startup. Of course, a potential problem may occur if the system changes critical settings and does not report that to Windows 95. It works well most of the time, but not always.
To turn off the Plug and Play configuration at startup, forcing Windows 95 to store the configuration settings, select the Resources tab in Control Panel | System after choosing the device. Some devices may also be controlled through their own applet, such as modems.
The keys in HKEY_DYN_DATA are shown in Figure 2.11. Depending on the system and installed features, there may be different keys in your system.
Figure 2.11. HKEY_DYN_DATA keys in Windows 95.
For more detail on the individual keys, subkeys, and values contained in HKEY_DYN_DATA,
see Appendix F, "A Closer
Look at HKEY_DYN_DATA."
HKEY_USERS contains only information about the default user settings and the logged-in user. Although the hives contain settings for all the users individually, the user settings are normally inaccessible unless the user is actually logged in to the network. These settings tell the system which icons to use, what groups are available, which Start menu to use, what colors and fonts to use, and what Control Panel options and settings will be available. The associated keys are shown for Windows NT in Figure 2.12 and for Windows 95 in Figure 2.13.
Figure 2.12. HKEY_USERS keys in Windows NT.
Figure 2.13. HKEY_USERS keys in Windows 95.
For more detail on the individual keys, subkeys, and values contained in HKEY_USERS,
see Appendix G, "A Closer Look at HKEY_USERS."
Instead of holding information for both the current user and the default users, HKEY_CURRENT_USER has mapped information only about the currently logged-in user. Notice the settings in Figure 2.14 for Windows NT, and the settings for Windows 95 in Figure 2.15.
Figure 2.14. HKEY_CURRENT_USER keys in Windows NT.
Figure 2.15. HKEY_CURRENT_USER keys in Windows 95.
For more detail on the individual keys, subkeys, and values contained in HKEY_CURRENT_USER,
see Appendix H, "A Closer Look at HKEY_CURRENT_USER."
The actual settings in the Registry are in the values. These values and the resulting data are actually the controlling items, the most basic of all the building blocks of the Registry. There are six different types of data in the Registry, three of which are based on text strings, and three that are other data types.
In the Registry, a string is text information. It could be the text that is a description of a type of file, or a label on a hardware device, or even text that appears when you log on. It can be alpha or numeric information, usually with a maximum of 255 characters per string of text.
REG_SZ stands for a simple text string. It is the most common type of value in the Registry, and many types of information can be entered into the NT String Editor dialog box, as shown in Figure 2.16. Descriptions, names, titles, paths, instructions, and other text items are examples of acceptable entries. The Windows 95 Edit String dialog box (shown in Figure 2.17) also shows the name of the value, but does not allow editing of the value name there.
Figure 2.16. The String Editor dialog box in Windows NT.
Figure 2.17. The Edit String dialog box in Windows 95.
A REG_SZ entry can also be a number. An example of the
use of numbers in
a REG_SZ entry is the entry of color saturation for RGB colors. In RGB color
notation, white is listed as 255 255 255 (representing red, green, and blue
saturation, respectively). White is full saturation. Red is
255 0 0 (full
saturation of the red value and no others), green is 0 255 0, and blue is
0 0 255. All other colors are a combination of those. Light green is 192
220 192 and navy is 0 0 128. Dates, version
numbers, and many other
types of information are also represented as numeric information in a string entry.
A REG_MULTI_SZ entry allows the use of a list of items for a single value. Multiple network transport protocols, multiple items, lists of devices, and other similar list-entry items are examples of the use of a REG_MULTI_SZ entry. Figure 2.18 shows the dialog box used for data entry for a REG_MULTI_SZ value.
Figure 2.18. The Multi-String Editor dialog box
Any items that would
normally be in a list are examples of a REG_MULTI_SZ
value. Items in a REG_MULTI_SZ value have multiple entries, each on its
own line when more than one entry is used (such as multiple IP addresses for a single
network card).
Windows 95 does not support REG_MULTI_SZ entries. Any items that are lists are entered as individual valuenames, or as comma-separated REG_SZ entries. The example shown in Figure 2.18, multiple IP addresses for a single network card, is not supported in Windows 95.
REG_EXPAND_SZ is the notation for an expandable string. The editor, shown in Figure 2.19, looks exactly the same as the editor for a standard REG_SZ string. The difference is based on the use of variables. When a variable is typed into the REG_EXPAND_SZ editor, the system uses it as a variable, and replaces the variable with the proper text when activated.
Figure 2.19. The String Editor dialog box.
An example would be the frequent use of
%SYSTEMROOT%, which, when activated,
would return the actual directory where the Windows NT files are located. %USERNAME%
is used as a variable, and is replaced by the logged-on user's name. %PROCESSORFAMILY%
would return
Intel, Alpha, MIPS, or PowerPC when
activated by the Registry.
Windows NT uses REG_EXPAND_SZ entries, but Windows 95 does not. That does not mean that 95 won't use variables. It does, but the 95 String Editor, used for editing REG_SZ entries, is intelligent enough to detect a variable and ensure that the system can use it.
WARNING: If you use a REG_SZ string entry in Windows NT when a variable entry (REG_EXPAND_SZ) is required, the Registry will not replace the variable with the correct information. It will simply return the actual variable as text.
The other three entries are numeric entries. REG_DWORD, REG_BINARY, and REG_RESOURCE_MAP allow numeric information to define settings for hardware and software items. Windows NT will use all three, but Windows 95 will only use REG_BINARY and REG_DWORD entries. Windows 95 still uses the same type of information, but always displays it as REG_BINARY entries in the Registry. In the Windows 95 Binary Editor, the data can be entered in binary code, using zeros and ones, or in hexadecimal. The actual numeric data for NT binary data can be entered in as Binary, Hexadecimal, or Decimal numeric entries. Those are three different ways to look at the same value, and depending on the type of data, one might be easier than the others. For example, the speed rating of a 100MHz processor might be listed as "1100011" in binary, "63" in hexadecimal, and "99" in decimal. In that circumstance, it is easier to work in decimal numbers. On the other hand, when you choose to disable the display of all the drives in the My Computer window, the decimal number is 67108863, but the binary equivalent is "11111111111111111111111111" (26 ones), each representing a drive letter to disable. In that case, editing in binary would be easier.
WARNING: Even though the processor is labeled 100MHz by Intel, and actually shows up here as 99MHz, it is really the same. The difference is in the rounding. Intel rounds up (it sounds better), and the Registry rounds down. Don't change it.
REG_DWORD data is 32-bit information, always displayed as 4 bytes. It is useful for error-control functions, and may be viewed or edited in the DWORD Editor in the NT Registry in hexadecimal, binary, or decimal format. In the main windows of REGEDT32.EXE or REGEDIT.EXE, though, it will always show as hexadecimal. Figure 2.20 shows the DWORD Editor with the optional data display types for the numeric data entry.
Figure 2.20. The DWORD Editor dialog box.
The DWORD Editor is also
used for the configuration of 32-bit components of application
and operating-system software, for IRQ and other settings, and for dates.
REG_BINARY differs from REG_DWORD in that REG_BINARY can be any length, while REG_DWORD must be 32 bits in length. Most hardware-component information is stored in binary format (zeros and ones) and may be any length of bytes (each byte is represented by a two-digit number). This data can be displayed in either the standard binary format, in hexadecimal format, or in applications like Windows NT Diagnostics as easily readable data.
The way to edit NT REG_BINARY information is with the Binary Editor, as shown in Figure 2.21. Be very careful to enter the exact information. One misplaced 0 or 1 makes the entry completely wrong, and can have disastrous results.
Figure 2.21. The Binary Editor dialog box in Windows NT.
Notice in Figure 2.22, the Binary Editor for Windows 95, that there are no other
listed
options for data entry besides binary entries, and everything is shown as
binary, with the hexadecimal equivalent showing at the right of the dialog box. You
can enter data in hexadecimal on the right side, and the binary equivalent will be
shown on
the left, or the reverse.
Figure 2.22. The Edit Binary Value dialog box in Windows 95.
In Windows NT,
REG_BINARY entries are quite rare. Most of the entries that
are used in binary format are limited to 32 bits, and then are used as REG_DWORD
entries. If a REG_DWORD entry were mistakenly entered as a REG_BINARY
entry, it would still work without a problem. REG_BINARY entries simply
have the flexibility to be longer.
In Windows 95, all 32-bit binary entries are shown as REG_BINARY, even though there is a REG_DWORD category. It's not until you actually edit the value that you can tell that it is a DWORD value.
The REG_FULL_RESOURCE_DESCRIPTOR value entry in the Registry allows you to see and edit the actual settings that a hardware device is using. The data is pulled from many separate locations and is centralized for easy viewing. The most common place for this type of entry is the HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System key and its enclosed values.
Figure 2.23 shows a full resource descriptor dialog box with its entries. The resources listed are the settings for a specific device, required for the system to configure it correctly.
Figure 2.23. A full resource descriptor dialog box in the Registry.
The
Resource Lists value entry in the Registry is used when there is more than one
set of full resource descriptors for a specific hardware device such as memory or
network cards. The Resource Lists dialog box appears, as shown in Figure 2.24, allowing
you to choose the type of resource list you want to see, and then the resource descriptor
dialog box appears, allowing you to see and edit the entries.
Figure 2.24. A Resource Lists dialog box in the Registry.
The structure of the Registry is based on a hierarchical database of information that the operating system uses to configure itself, to activate and use hardware and software, and to present an acceptable interface to the user.
Windows 95 and Windows NT show the data in the Registry in different ways, but the same type of data is available. Characteristically, Windows 95 entries are easier to read, using REGEDIT.EXE, but Windows NT entries, shown in this chapter in REGEDT32.EXE, allow for more detail, which leads to greater control and easier editing.
© Copyright, Macmillan Computer Publishing. All rights reserved.
