5.2.6 Values

4 min read

A value is a named, typed datum inside a key. Values hold the configuration data; keys hold values.

A key holds many values with distinct names, and at most one unnamed one.

5.2.6.1 One name, many entries #

A single (key GUID, value name) pair can have several entries in the source — one per layer that has written to it.

The source stores them all and returns them all.

LCS resolves the effective value at read time (§5.3.6).

That is the mechanism that makes layer deletion revert configuration automatically. Delete the layer, its entries go, and the next-highest-precedence entry becomes effective. Nothing has to be recomputed or rewritten.

5.2.6.2 Types #

The full Windows type set is supported, for registry.pol fidelity: REG_NONE, REG_SZ, REG_EXPAND_SZ, REG_BINARY, REG_DWORD, REG_DWORD_BIG_ENDIAN, REG_LINK, REG_MULTI_SZ, REG_RESOURCE_LIST, REG_FULL_RESOURCE_DESCRIPTOR, REG_RESOURCE_REQUIREMENTS_LIST and REG_QWORD, numbered 0 to 11. Values are in §5.A.

LCS stores the type tag and returns it on read but does not interpret the data. The single exception is REG_LINK read as a symlink key's default value, which triggers target resolution (§5.2.4).

The three hardware-resource types, 8 to 10, describe device resource assignments in the Windows HKLM\HARDWARE hive, which the Windows kernel rebuilds at every boot. Peios has no equivalent: hardware enumeration belongs to the Linux device model, sysfs and /proc/iomem, not to the registry. LCS accepts these tags only so a value carrying one round-trips without loss. They have no semantics, LCS never produces one, and for every operation they behave as REG_BINARY. Rejecting a faithfully-copied value would break the fidelity guarantee that is the reason the registry exists.

Type tags are validated at every write boundary, before sequence allocation, transaction enlistment or source dispatch. An unknown code is EINVAL.

5.2.6.3 REG_TOMBSTONE #

One further type, REG_TOMBSTONE (0xFFFF), is internal. It is never returned to a caller reading a value — a caller whose effective entry is a tombstone gets ENOENT, which is exactly what a tombstone means.

There is no separate tombstone flag in the REG_IOC_SET_VALUE argument. Writing type REG_TOMBSTONE is the explicit tombstone operation.

It must carry zero-length data; non-empty tombstone data is EINVAL, again before sequence allocation, enlistment or dispatch.

5.2.6.4 Naming #

Value names use the same case rules as key names: Unicode Simple Case Folding, case-preserving, case-insensitive.

They differ in one respect. Backslash and forward slash are permitted in a value name. Value names are not hierarchical, so a separator has no meaning in one.

Only the null byte is forbidden, and invalid UTF-8 is rejected. The empty string is reserved for the default value.

That difference is why watch event path components are length-prefixed rather than joined by a separator (§5.6.2) — a value name can contain the separator.

5.2.6.5 Size #

MaxValueSize defaults to 1 MB and is configurable from 4 KB to 64 MB (§5.10.3).

Value data is opaque bytes and is not subject to the UTF-8 validation that applies to every string in the interface.

5.2.6.6 Tool value encodings #

reg, Registry Editor and the peios Rust crate use these representations:

• REG_SZ and REG_EXPAND_SZ: UTF-8 ending in one null byte, rather than Windows' UTF-16 representation.
• REG_LINK: the absolute target path in UTF-8, with no null byte. Its length determines its end; a target containing a null is not followed.
• REG_MULTI_SZ: each string followed by a null byte, with one additional null byte ending the list.
• Integers: little-endian, except for REG_DWORD_BIG_ENDIAN.

These are data conventions shared by tools. LCS still treats ordinary value payloads as opaque bytes; its special handling of a link key's REG_LINK default value is described in §5.2.4. For choosing and entering a type as an operator, see Keys, values, and types.

Edit this page