Understanding parse trees

You can define one or more parse trees in your registrar script, where each parse tree has the following form:

<root-key>{<registry expression>}+

where:

<root-key> ::=
 HKEY_CLASSES_ROOT | HKEY_CURRENT_USER |
 HKEY_LOCAL_MACHINE | HKEY_USERS |
 HKEY_PERFORMANCE_DATA | HKEY_DYN_DATA |
 HKEY_CURRENT_CONFIG | HKCR | HKCU |
 HKLM | HKU | HKPD | HKDD | HKCC

<registry-expression> ::=
  <Add-Key> | <Delete-Key>

<Add-Key> ::=
  [ForceRemove | NoRemove | val] <Key-Name> [<Key-Value>] [ { <Add-Key> } ]

<Delete-Key> ::=
  Delete <Key-Name>

<Key-Name> ::=
  '<AlphaNumeric>+'

<AlphaNumeric> ::=
  any non-null character.

<Key-Value> ::=
  <Key-Type> <Key-Name>

<Key-Type> ::=
  s | d

A parse tree can add multiple keys and subkeys to the <root-key>. The Registrar keeps each subkey handle open until the parser has completed parsing all of its subkeys. It's more efficient than operating on a single key at a time. Here's an example:

HKEY_CLASSES_ROOT
{
    'MyVeryOwnKey'
    {
        'HasASubKey'
        {
            'PrettyCool'
        }
    }
}

Here, the Registrar initially opens (creates) HKEY_CLASSES_ROOT\MyVeryOwnKey. It then sees that MyVeryOwnKey has a subkey. Rather than close the key to MyVeryOwnKey, the Registrar keeps the handle and opens (creates) HasASubKey using this parent handle. (The system registry can be slower when no parent handle is open.) So, opening HKEY_CLASSES_ROOT\MyVeryOwnKey and then opening HasASubKey with MyVeryOwnKey as the parent is faster than opening MyVeryOwnKey, closing MyVeryOwnKey, and then opening MyVeryOwnKey\HasASubKey.

See also

Creating registrar scripts