|
The Windows registry is a directory which stores settings and options for the operating system for Microsoft Windows 32-bit versions, 64-bit versions, and Windows Mobile. It contains information and settings for all the hardware, operating system software, most non-operating system software, users, preferences of the PC, etc. Whenever a user makes changes to Control Panel settings, file associations, system policies, or most installed software, the changes are reflected and stored in the registry. The registry also provides a window into the operation of the kernel, exposing runtime information such as performance counters and currently active hardware. This use of registry mechanism is conceptually similar to the way that Sysfs and procfs expose runtime information through the file system (traditionally viewed as a place for permanent storage), though the information made available by each of them differs tremendously.
The Windows registry was introduced to tidy up the profusion of per-program INI files that had previously been used to store configuration settings for Windows programs.[1] These files tended to be scattered all over the system, which made them difficult to track.
Structure
Keys and values
The registry contains two basic elements: keys and values.
Registry Keys are similar to folders - in addition to values, each key can contain subkeys, which may contain further subkeys, and so on. Keys are referenced with a syntax similar to Windows' path names, using backslashes to indicate levels of hierarchy. E.g. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows refers to the subkey "Windows" of the subkey "Microsoft" of the subkey "Software" of the HKEY_LOCAL_MACHINE key.
Registry Values are name/data pairs stored within keys. Values are referenced separately from keys. Value names can contain backslashes but doing so makes them difficult to distinguish from their key paths. The Windows API functions that query and manipulate registry values take value names separately from the key path and/or handle that identifies the parent key.
The terminology is somewhat misleading, as the values are similar to an associative array, where standard terminology would refer to the name part of the value as a "key". The terms are a holdout from the 16-bit registry in Windows 3, in which keys could not contain arbitrary name/data pairs, but rather contained only one unnamed value (which had to be a string). In this sense, the entire registry was like an associative array where the keys (in both the registry sense and dictionary sense) formed a hierarchy, and the values were all strings. When the 32-bit registry was created, so was the additional capability of creating multiple named values per key, and the meanings of the names were somewhat distorted[2].
Hives
The Registry is split into a number of logical sections, or "hives".[3] Hives are generally named by their Windows API definitions, which all begin "HKEY". They are abbreviated to a three- or four-letter short name starting with "HK" (e.g. HKCU and HKLM).
The HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER nodes have a similar structure to each other; applications typically look up their settings by first checking for them in "HKEY_CURRENT_USER\Software\Vendor's name\Application's name\Version\Setting name", and if the setting is not found look instead in the same location under the HKEY_LOCAL_MACHINE key. When writing settings back, the reverse approach is used — HKEY_LOCAL_MACHINE is written first, but if that cannot be written to (which is usually the case if the logged-in user is not an administrator), the setting is stored in HKEY_CURRENT_USER instead.
HKEY_CLASSES_ROOT (HKCR)
Abbreviated HKCR, HKEY_CLASSES_ROOT stores information about registered applications, such as file associations and OLE Object Class IDs tying them to the applications used to handle these items. On Windows 2000 and above, HKCR is a compilation of HKCU\Software\Classes and HKLM\Software\Classes. If a given value exists in both of the subkeys above, the one in HKCU\Software\Classes is used.[4]
HKEY_CURRENT_USER (HKCU)
Abbreviated HKCU, HKEY_CURRENT_USER stores settings that are specific to the currently logged-in user. The HKCU key is a link to the subkey of HKEY_USERS that corresponds to the user; the same information is reflected in both locations. On Windows-NT based systems, each user's settings are stored in their own files called NTUSER.DAT and USRCLASS.DAT inside their own Documents and Settings subfolder (or their own Users subfolder in Windows Vista). Settings in this hive follow users with a roaming profile from machine to machine.
HKEY_LOCAL_MACHINE (HKLM)
Abbreviated HKLM, HKEY_LOCAL_MACHINE stores settings that are general to all users on the computer. On NT-based versions of Windows, HKLM contains four subkeys, SAM, SECURITY, SOFTWARE and SYSTEM, that are found within their respective files located in the %SystemRoot%\System32\Config folder. A fifth subkey, HARDWARE, is volatile and is created dynamically, and as such is not stored in a file. Information about system hardware drivers and services are located under the SYSTEM subkey, while the SOFTWARE subkey contains software and Windows settings.
HKEY_USERS (HKU)
Abbreviated HKU, HKEY_USERS contains subkeys corresponding to the HKEY_CURRENT_USER keys for each user profile actively loaded on the machine, though user hives are usually only loaded for currently logged-in users.
HKEY_CURRENT_CONFIG
Abbreviated HKCC, HKEY_CURRENT_CONFIG contains information gathered at runtime; information stored in this key is not permanently stored on disk, but rather regenerated at the boot time.
HKEY_PERFORMANCE_DATA
This key provides runtime information into performance data provided by either the NT kernel itself or other programs that provide performance data. This key is not displayed in the Registry Editor, but it is visible through the registry functions in the Windows API.
HKEY_DYN_DATA
This key is used only on Windows 95, Windows 98 and Windows Me. [5] It contains information about hardware devices, including Plug-and-Play and network performance statistics. The information in this hive is also not stored on the hard drive. The Plug and Play information is gathered and configured at startup and is stored in memory. [6]
Symbolic Links
In Windows NT based systems Symbolic Links between registry keys are supported through REG_LINK value type. Registry links work similarly to file shortcuts or filesystem Symbolic links. As such they can span across different hives, however only those visible in Native API namespace, that is \Registry\Machine and \Registry\User. Other hives like HKEY_DYN_DATA are only virtual objects in Win32 API and thus not linkable. Links are used in Windows rather scarcely, only by CurrentControlSet and Hardware Profiles\Current. [7]
Editing
The registry can be edited manually in Microsoft Windows by running regedit.exe or regedt32.exe in the Windows directory. However, careless registry editing can cause irreversible damage. Thus, performing backups of the registry before editing it is highly recommended. Many optimization and "hacking" tools are available to modify this portion of the Windows operating system; it is preferable not to use them unless one has a knowledge of registry workings or wishes to learn more about the registry.
The Registry Editor allows users to perform the following functions:
* Creating, manipulating, renaming and deleting registry keys, subkeys, values and value data * Importing and exporting .REG files, exporting data in the binary hive format * Loading, manipulating and unloading registry hive format files (Windows NT-based systems only) * Setting permissions based on ACLs (Windows NT-based systems only) * Bookmarking user-selected registry keys as Favorites * Finding particular strings in key names, value names and value data * Remotely editing the registry on another networked computer
.REG files
.REG files (also known as Registration entries) are text-based human-readable files for storing portions of the registry. On Windows 2000 and later NT-based operating systems, they contain the string Windows Registry Editor Version 5.00 at the beginning and are Unicode-based. On Windows 9x and NT 4.0 systems, they contain the string REGEDIT4 and are ANSI-based. [11] Windows 9x format .REG files are compatible with Windows 2000 and later NT-based systems. The Registry Editor on Windows on these systems also supports exporting .REG files in Windows 9x/NT format.
Locations
The Registry is stored in several files; depending upon the version of Windows, there will be different files and different locations for these files, but they are all on the local machine. The user-specific HKEY_CURRENT_USER user registry hive is stored in Ntuser.dat. There is one of these per user; if a user has a roaming profile, then this file will be copied to and from a server at logout and login respectively.
Windows NT-based operating systems
Windows NT-based systems store the registry in a binary hive format which is the same format that can be exported, loaded and unloaded by the Registry Editor in these operating systems. The following Registry files are stored in %SystemRoot%\System32\Config\:
* Sam – HKEY_LOCAL_MACHINE\SAM * Security – HKEY_LOCAL_MACHINE\SECURITY * Software – HKEY_LOCAL_MACHINE\SOFTWARE * System – HKEY_LOCAL_MACHINE\SYSTEM * Default – HKEY_USERS\.DEFAULT * Userdiff – Not associated with a hive. Used only when upgrading operating systems.[14]
The following files are stored in each user's profile folder:
* %UserProfile%\Ntuser.dat – HKEY_USERS\<User SID> (linked to by HKEY_CURRENT_USER) * %UserProfile%\Local Settings\Application Data\Microsoft\Windows\Usrclass.dat (path is localized) – HKEY_USERS\<User SID>_Classes (HKEY_CURRENT_USER\Software\Classes)
Windows 2000 keeps an alternate copy of the registry hives (.ALT) and attempts to switch to it when corruption is detected.[15] Windows XP and Windows Server 2003 do not maintain a System.alt hive because NTLDR on those versions of Windows can process the System.log file to bring up to date a System hive that has become inconsistent during a shutdown or crash. In addition, the %Windir%\Repair folder contains a copy of the system's registry hives that were created after installation and the first successful startup of Windows.
Group policy
Windows 2000 and later versions of Windows use Group Policy to enforce Registry settings. Policy may be applied locally to a single computer using GPEdit.msc, or to multiple computers in a domain using gpmc.msc.
Inifile virtualization
Windows NT kernels support redirection of INI file-related API's into a virtual file in a Registry location such as HKEY_CURRENT_USER using a feature called "InifileMapping".[16] This functionality was introduced to allow legacy applications written for 16-bit versions of Windows to be able to run under Windows NT platforms on which the System folder is no longer considered an appropriate location for user-specific data or configuration. Non-compliant 32-bit applications can also redirected in this manner, even though the feature was originally intended for 16-bit applications.
Registry virtualization
Windows Vista has introduced limited Registry virtualization, whereby poorly written applications that write user data to a read-only system location (such as the HKEY_LOCAL_MACHINE hive) can be redirected to a more appropriate location, without changing the application itself. The operation is transparent to the application, as it does not know that its Registry operations have been directed elsewhere.
Similarly, application virtualization redirects all of an application's Registry operations to a non-Registry backed location, such as a file. Used together with file virtualization, this approach allows applications to run without being installed on the location machine.
Lastly, the Application Compatibility Toolkit[17] provides shims that can transparently redirect HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT Registry operations to HKEY_CURRENT_USER to address "LUA" bugs that cause applications not to work for limited users. This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia.
|