Geoff Chappell - Software Analyst
As with any large program, Internet Explorer has many registry settings. Internet Explorer 8 brings thousands of settings together for common handling. The settings are defined in various tables throughout IERTUTIL and are made accessible through a large set of exported functions:
Most of these functions take as their first argument a GUID that represents a setting. The IERTUTIL from Windows 7 knows of 4,714 values and 524 keys. I do not intend any time soon to extract the list and arrange it for publication. That work should be someone’s commercial exercise.
Each setting may be stored at the same position relative to as many as four keys depending on whether it is to represent a user’s preference or be imposed by administrative policy. The functions treat these branches as logical hives, each represented by a Hive ID that some functions take as their second argument. Other functions iterate through the hives in order of decreasing precedence:
| Hive ID | Path | Interpretation |
|---|---|---|
| 0 | HKEY_LOCAL_MACHINE\Software\Policies | administrative policy for all users |
| 1 | HKEY_CURRENT_USER\Software\Policies | administrative policy for current user |
| 2 | HKEY_CURRENT_USER\Software | preference for current user, can be configured by current user |
| 3 | HKEY_LOCAL_MACHINE\Software | administrative preference for all users, can be overridden by current user |
The merit in reproducing a value in multiple locations lies in the combination of applicability and access. A setting in either of the HKEY_LOCAL_MACHINE branches is intended for all users, but the same setting in either of the HKEY_CURRENT_USER branches is meant just for the current user. Indeed, what the system presents as HKEY_CURRENT_USER is different for different users. A setting that is stored beneath either of the Software\Policies keys or in either of the HKEY_LOCAL_MACHINE branches typically cannot be modified except with administrative privilege.
The first branch therefore sets a machine-wide policy, with no exception. The second branch allows an administrator to write different policies for particular users, but the machine-wide policy has precedence. Though a user can typically write the setting in the HKEY_CURRENT_USER\Software key, there may be no effect since all policies apply before all preferences. Note the reversal of machine and user branches in moving from policies to preferences. The last branch also applies machine-wide, like the first, but it has little force: users are free to override it in their HKEY_CURRENT_USER\Software branch.
Each setting has an intrinsic type, which several functions expect to be specified as an argument:
| Type ID | Interpretation | Remarks |
|---|---|---|
| 0 | BOOL | REG_DWORD, with non-zero as true, zero as
false; REG_SZ, with case-insensitive yes, true or 1 as true, no, false or 0 as false |
| 1 | DWORD | REG_DWORD; REG_BINARY if exactly 4 bytes |
| 2 | String | REG_SZ |
| 3 | REG_EXPAND_SZ | |
| 4 | StringArray | REG_MULTI_SZ |
| 5 | Binary | REG_BINARY |
| 6 | REG_BINARY | |
| 7 | BOOLExt | as for 0 but with placeholders for the setting’s key and value |
| 8 | DWORDExt | as for 1 but with placeholders for the setting’s key and value |
| 9 | StringExt | as for 2 but with placeholders for the setting’s key and value |
| 10 | as for 4 but with placeholders for the setting’s key and value | |
| 11 | BinaryExt | as for 5 but with placeholders for the setting’s key and value |
| 12 | REG_BINARY |
Within IERTUTIL, the hive and type are each defined as an enum, named HIVEID and TYPE respectively, in the SettingStore namespace. Although the exported functions, which all have C-language linkage, could be defined to use types from a namespace, these notes assume they are not, so that arguments that specify the hive and type are simple integers. Some support for this is provided by relevant methods of the ISettingsBroker interface: the decorated names shown in the IERTUTIL symbol file have int for both arguments.