In modern Windows platforms, the Registry has five root keys that contain nonvolatile data. Three of these, however, are actually pointers to specific branches within the other two. To avoid processing the same Registry data twice, InCtrl5 must identify and skip the equivalents of HKEY_CLASSES_ROOT and HKEY_CURRENT_CONFIG within HKEY_LOCAL_MACHINE, and the equivalent of HKEY_CURRENT_USER within HKEY_USERS. The code that handles these tasks is found in the module Regequiv.pas.

HKEY_CLASSES_ROOT is easy to handle, as it always points to HKEY_LOCAL_MACHINE\Software\Classes. On a Windows 9x machine, HKEY_CURRENT_USER usually points to HKEY_USERS\username, where username is the data for the value Current User under the key HKEY_LOCAL_MACHINE\System\ CurrentControlSet\control. Under Windows NT 4.0 or 2000, InCtrl5 must perform a fairly complex analysis to determine the Security ID (SID) for the current user, as HKEY_CURRENT_USER points to the subkey of HKEY_USERS whose name is the current user's SID. On all platforms, InCtrl5 tests the found key as described below. If the test fails, it checks every subkey of HKEY_USERS to determine which one represents HKEY_CURRENT_USER.

Under the Windows NT family, HKEY_CURRENT_CONFIG has four equivalents within HKEY_LOCAL_MACHINE. To identify them, InCtrl5 reads the DWORD value CurrentConfig from the Registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet \control\IDConfigDB. The four equivalent keys are:
HKEY_LOCAL_MACHINE\SYSTEM\ ControlSet###\Hardware Profiles\Current
HKEY_LOCAL_MACHINE\SYSTEM\ ControlSet###\Hardware Profiles\###
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Hardware Profiles\###
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Hardware Profiles\Current where ### is the CurrentConfig value expressed as a three-digit number. Under Windows 9x, the CurrentConfig value is a string, and the equivalent is HKEY_LOCAL_MACHINE\CONFIG\####, where #### is the stored number. As before, InCtrl5 tests the equivalent keys before accepting them.

It's important that InCtrl5 identify these equivalents accurately. First, the program tests each of them by calling the user-defined function TestKey(). TestKey() creates a subkey and value, each with a unique name, under the specified key, and then attempts to read back the value using the supposed equivalent key. If this test succeeds, the equivalency is guaranteed. If the user doesn't have sufficient privileges to write to the Registry, though, the test will fail.

In that case, a second user-defined function -- CompareKeyInfo() -- is called. This function gets all the information it can about the two keys using the API function RegQueryInfoKey(). The returned data includes the number of subkeys and values, the length of the longest subkey and value name, and the size of the largest value data. It's extremely unlikely that nonequivalent keys would have precisely the same values for all of these characteristics.