Geoff Chappell - Software Analyst
From version 5.00 onwards, SHLWAPI provides a set of functions for supporting a common type of registry setting that appears to be called a restriction.
Each restriction is implemented in the registry as a DWORD value at the same location in either of the HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER branches, the former having precedence. If the value is not present at either location, the restriction evaluates as zero.
A registry value with these characteristics is most useful as a restriction if a non-zero value is interpreted as restricting some feature that would ordinarily be enabled, or even be taken for granted. If the location is one to which ordinary users do not have write access, then the restriction has the force of an administrative policy. However, it seems to be no business of SHLWAPI’s whether restrictions actually are used this way. A non-zero value might just as easily be interpreted as allowing some feature that would ordinarily be disabled.
The SHGetRestriction function can get the value of any single restriction by naming it as a registry value and saying where to find it.
Greater utility comes from defining a set of restrictions. These can be spread throughout some registry key, even in different subkeys, with each value in the set being represented by an ID so that the names of keys, subkeys and values become implementation details. Not only can the SHRestrictionLookup function get the value of any restriction in such a set, but it manages the set as one, including to cache the values (in memory provided by the caller) rather than keep querying the registry.
Should an operation initiated by a user conflict with some restriction, so that it cannot be permitted to proceed, then the SHRestrictedMessageBox function is available for telling the user why in a standard way.