Windows registry

So we were talking about the Windows registry last week and reader Keith Medcalf wrote in to point out that, “Actually, the registry was invented by IBM for Presentation Manager (the graphical interface layer to OS/2) in 1988-89. . . . Microsoft, having access to the registry under the Joint Application Development, used the registry database for its own Windows system.” Medcalf also notes that “the registry first appeared in Windows Version 3.0, for registration of DDE [which morphed into OLE], which Microsoft later adapted and renamed ActiveX.”

Medcalf goes on about the history and concludes by pointing out, “Microsoft did promote using the registry to store application configuration information, and eventually over time moved all configuration information. . . . This misadventure led to the situation that exists today – the chicken and egg problem. You cannot correct an error in the registry unless the operating system is fully operating. Of course, the primary reason for needing to edit the registry is because something is broken, and if something is broken you cannot run enough of the operating system to edit the registry. Microsoft introduced all sorts of shenanigans to get around this silly state of affairs so they created “Safe Mode”, “Recovery Console”, “Safe Mode VGA Only” [and so on].”

Thanks, Mr. Medcalf. We are not surprised to find that the whole mess is even worse, architecturally and practically speaking, than we ever thought.

Last week we mentioned the registry hives and you might have concluded that there are five of them, which is how things appear. Actually, there are only two: HKEY_LOCAL_MACHINE and HKEY_USERS. The other hives are subtrees of the data in the two real hives – this is partly for convenience to make accessing the data simpler and partly for compatibility.

Thus, HKEY_CURRENT_CONFIG is an alias for HKEY_LOCAL_MACHINESYSTEMCurrentControlSetHardware ProfilesCurrent, and HKEY_CLASSES_ROOT is an alias for HKEY_LOCAL_MACHINESOFTWAREClasses.

HKEY_CURRENT_USER is a little different: It points to one of the subkeys of HKEY_USERS – which one depends on the security identifier (SID) of the currently logged-on user of the operating system.

SIDs are long numeric sequences such as “HKEY_USERSS-1-5-21-725345543-1580436667-839522115-1003,” and they are unique. This means that Windows can never reuse a SID. So while a name associated with a SID (such as the name of a user, group or domain) might change, the value of the SID will not.

Note that encoded in the SID value is the ID of the domain that issued the SID. A consequence of this is that if you migrate users or groups from one domain to another, a new SID must be issued so the original access permissions for those entities will change.

The logical structure of the registry appears to be five root keys or hives, but is actually two root keys and three aliases to subkeys of those root keys. The hives are stored in several separate files on disk

For the following subkeys under the HKEY_LOCAL_MACHINE hive you’ll find the following files under “%systemroot%system32config” (we’ve listed them as Hive subkey – Files): SAM – Sam, Sam.log, Sam.sav; Security – Security, Security.log, Security.sav; Software – Software, Software.log, Software.sav; System – System, System.alt, System.log, System.sav.

You’ll also find the hive HKEY_CURRENT_CONFIG under “%systemroot%system32config” in the files System, System.alt, System.log and System.sav; while the files for HKEY_CURRENT_USER (Ntuser.dat, Ntuser.dat.log) and KEY_USERSDEFAULT (Default,Default.log,Default.sav) are found under “%systemroot%%userprofile%”.

In the above lists, a file name with no extension is a complete copy of the hive data, while a “log” file is a log of changes to the keys and values.

Also, “alt” files are back-up copies of their respective subkeys under the HKEY_LOCAL_MACHINESystem hive. Only the System key has an .alt file and so the reason HKEY_CURRENT_CONFIG has one because it is actually a subkey (or subhive) of the System key.

Finally, “sav” files are copies of hive files, as they were at the end of the text-mode stage in Windows setup to save the configuration data should the graphics-mode stage of setup fail. So if setup goes “THUD!” in the graphics-mode stage, the hive data is restored from the “sav” file on restart and only the graphics-mode stage is repeated. Groovy.

“Enough” you cry . . . just you wait until next week!

“Woe is us” to gearhead@gibbs.com.