What is the Windows Registry? From Wikipedia, the free encyclopedia The Windows Registry is a database that stores settings and options for Microsoft Windows operating systems. It contains information and settings for hardware, operating system software, most non-operating system software, and per-user settings. The registry also provides a window into the operation of the kernel, exposing runtime information such as performance counters and currently active hardware. When first introduced with Windows 3.1, the Windows registry's purpose was to tidy up the profusion of per-program INI files that had previously been used to store configuration settings for Windows programs. 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. There are six Root Keys: HKEY CLASSES ROOT HKEY CURRENT USER HKEY LOCAL MACHINE HKEY USERS HKEY CURRENT CONFIG HKEY DYN DATA Registry Values are named 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. There are a number of different types of values: List of Registry Value Types 0 REG_NONE No type 1 REG_SZ A string value 2 REG_EXPAND_SZ An "expandable" string value that can contain environment variables 3 REG_BINARY Binary data (any arbitrary data) 4 REG_DWORD/REG_DWORD_LITTLE_ENDIAN A DWORD value, a 32-bit unsigned integer (numbers between 0 and 4,294,967,295 [232 – 1]) (little-endian) 5 REG_DWORD_BIG_ENDIAN A DWORD value, a 32-bit unsigned integer (numbers between 0 and 4,294,967,295 [232 – 1]) (big-endian) 6 REG_LINK symbolic link (UNICODE) 7 REG_MULTI_SZ A multi-string value, which is an array of unique strings 8 REG_RESOURCE_LIST Resource list 9 REG_FULL_RESOURCE_DESCRIPTOR Resource descriptor 10 REG_RESOURCE_REQUIREMENTS_LIST Resource Requirements List 11 REG_QWORD/REG_QWORD_LITTLE_ENDIAN A QWORD value, a 64-bit integer (either big- or little-endian, or unspecified) (Introduced in Windows 2000) 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 in that they can span across different hives, but 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 for only CurrentControlSet and Hardware Profiles\Current. Aliases Aliases in the windows 9x registry: Root key Aliases for HKEY_CLASSES_ROOT HKEY_LOCAL_MACHINE\Software\Classes HKEY_CURRENT_USER User’s branch within HKEY_USERS HKEY_CURRENT_CONFIG Hardware profile within HKEY_LOCAL_MACHINE\Config Manual editing of the Windows Registry <shapetypeid_x0000_t75strokedffilledfpathm@4@5l@4@11@9@11@9@5xeo:preferrelativeto:spt75coordsize21600,21600><strokejoinstylemiter><formulas><feqnif lineDrawn pixelLineWidth 0><feqnsum @0 1 0><feqnsum 0 0 @1><feqnprod @2 1 2><feqnprod @3 21600 pixelWidth><feqnprod @3 21600 pixelHeight><feqnsum @0 0 1><feqnprod @6 1 2><feqnprod @7 21600 pixelWidth><feqnsum @8 21600 0><feqnprod @7 21600 pixelHeight><feqnsum @10 21600 0><patho:connecttyperectgradientshapeokto:extrusionokf><lockaspectratiotv:extedit> Windows 3.11 Registry Editor 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 by Microsoft and many industry experts (such as the authors and editors of leading trade magazines). A simple implementation of the current registry tool appeared in Windows 3.x, called the "Registration Info Editor" or "Registration Editor". This was basically just a database of applications used to edit embedded OLE objects in documents. Windows 9x operating systems include REGEDIT.EXE which can be used in Windows and also in real mode MS-DOS. Windows NT introduced permissions for Registry editing. Windows NT 4.0 and Windows 2000 were distributed with both the Windows 9x REGEDIT.EXE program and Windows NT 3.x's REGEDT32.EXE program. There are several differences between the two editors on these platforms: REGEDIT.EXE has a left-side tree view that begins at "My Computer" and lists all loaded hives. REGEDT32.EXE has a left-side tree view, but each hive has its own window, so the tree displays only keys. REGEDIT.EXE represents the three components of a value (its name, type, and data) as separate columns of a table. REGEDT32.EXE represents them as a list of strings. REGEDIT.EXE supports right-clicking of entries in a tree view to adjust properties and other settings. REGEDT32.EXE requires all actions to be performed from the top menu bar. REGEDIT.EXE supports searching for key names, values, or data throughout the entire registry, whereas REGEDT32.EXE only supports searching for key names in one hive at a time. Because REGEDIT.EXE was directly ported from Windows 95, it does not support editing permissions. (Permissions do not exist on Windows 9x). Therefore, of the two, only REGEDT32.EXE can access the full functionality of an NT registry. REGEDIT.EXE only supports string (REG_SZ), binary (REG_BINARY), and DWORD (REG_DWORD) values. REGEDT32.EXE supports those, plus expandable string (REG_EXPAND_SZ) and multi-string (REG_MULTI_SZ). Attempting to edit unsupported key types with REGEDIT.EXE on Windows 2000 or Windows NT 4.0 will result in irreversible conversion to a supported type. Windows XP was the first system to integrate these two programs into one, adopting the old REGEDIT.EXE interface and adding the REGEDT32.EXE functionality. The differences listed above are not applicable on Windows XP and newer systems; REGEDIT.EXE is the improved editor, and REGEDT32.EXE is simply a stub that invokes REGEDIT.EXE. 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 It also possible to edit the registry under Linux using the opensource Offline NT Password & Registry Editor to edit the files. Policy Legacy systems With Windows 95, Windows 98, Windows Me and Windows NT, administrators can use a special file to be merged into the registry, called a policy file (POLICY.POL). The policy file allows administrators to prevent non-administrator users from changing registry settings like, for instance, the security level of Internet Explorer and the desktop background wallpaper. The policy file is primarily used in a business with a large number of computers where the business needs to be protected from rogue or careless users. The default extension for the policy file is .POL. The policy file filters the settings it enforces by user and by group (a "group" is a defined set of users). To do that the policy file merges into the registry, preventing users from circumventing it by simply changing back the settings. The policy file is usually distributed through a LAN, but can be placed on the local computer. Advantages and disadvantages The Windows centralized Registry has a number of advantages over legacy INI files: Strongly-typed data can be stored in the Registry, as opposed to only textual information in INI files. Separation of machine configuration from user configuration. When a user logs into a Windows NT/2000/XP/Server 2003 computer, the user-based registry settings are loaded from a user-specific path rather than from a read-only system location. This allows multiple users to share the same machine, and also allows programs to work for a least-privilege user. Group Policy allows administrators on a Windows-based computer network to centrally manage program and policy settings. Part of this involves being able to set what an entry in the registry will be for all the computers on the network, and affect nearly any installed program — something almost impossible with per-program configuration files each with custom layouts, stored in dispersed locations. Standardization of the method of storing configuration data across diverse applications. The registry can be accessed over a network connection for remote management/support, including from scripts, using the standard set of APIs, as long as the Remote Registry service is running and firewall rules permit this. The entire registry can be backed up more easily as it is just a small number of files in specific locations. However, it is much harder to back up and restore configuration of a specific application. Since accessing the registry does not require parsing, it can be read from and written to more quickly than a text file can be. However, the registry becomes a large file to process once per boot. Portions of settings like any subset of an application configuration can be saved in a text-based .REG file, which can be edited with any text editor later. .REG files can easily be merged back into the registry both by unattended batch file or by the user just double-clicking on the file without harming any setting that is not explicitly stated in the .REG file. This is very useful for administrators and support personnel who want to pre-set or pre-configure only a few options like approving the EULA of a certain application. The registry is constructed as a database, and offers DB-like features such as atomic updates. If two processes attempt to update the same registry value at the same time, one process's change will precede the other's, so one will only last a short time until the second gets written. With changes in a file system, such race conditions can result in interleaved data that doesn't match either attempted update. Windows Vista provides transactional updates to the registry, so the atomicity guarantees can be extended across multiple key and/or value changes, with traditional commit-abort semantics. (Note that NTFS provides such support for the file system as well, so the same guarantees could be obtained with traditional configuration files.) However, the centralized Registry introduces some problems as well: Centralizing configurations makes it difficult to back up and recover individual applications. In practice, manual manipulation of the registry might be required where applications that are using the Registry do not implement configuration through their user interface. Because the Registry structure is contained in binary files, damage to it is difficult to repair. In some cases, a damaged registry may even prevent a Windows system from booting successfully. Any application that does not uninstall properly, or does not have an uninstaller, can leave entries in the registry. Over time the computer suffers "software rot" as the registry fills with left-over and possibly incorrect entries. Installers and uninstallers become complex, much more than just copying files into a folder. Applications that make use of the registry to store and retrieve their settings are unsuitable for use on portable devices used to carry applications from one system to another. With a large amount of data stored in a configuration the speed of creating such a config in registry (install) becomes an issue. Since an application's configuration is centralized away from the application itself, it is often not possible to copy installed applications that use the Registry to another computer. This means that software usually has to be reinstalled from original media on a computer upgrade or rebuild, rather than just copying the user and software folder to the new computer. References ·         Russinovich, Mark E.; Solomon, David A. (2005). Microsoft Windows Internals (Fourth Edition ed.). Microsoft Press. pp. 183–236. ISBN 978-0-7356-1917-3.