Modify Values & Data In A
The model I had in mind at the time was Apple’s resource manager. This idea didn’t seem to gain any traction at all, but I still believe I was correct, and the lack of clear metadata was a design flaw that has led to endless messes. Windows also uses an unhealthy dose of security-through-obscurity. It hides password salts in the obscure “ClassName” field of the Registry key. The “security” here relies entirely on the fact that the default Windows REGEDIT program cannot view or edit the ClassName of a key.
It could benefit from indices to allow quick lookups, but instead we have to manually and linearly traverse it. If you browse through the Registry some time you’ll see it’s a giant accreted mess of non-standardized, overlapping information stored in random places. Some of it is configuration, much of it is runtime data. The major difference is that this Registry filesystem format is half-arsed. The format is badly constructed, fragile, endian-specific, underspecified and slow.
Anyone with a binary editor can get around this restriction trivially. Despite the fact that the Registry is just a plain file that you can modify using all sorts of external tools (eg. our hivex shell), you can create “unreadable” and “unwritable” keys. These are “secure” from the point of view of Windows, unless you just modify the Registry binary file directly. Back to point 1, the Registry is a half-assed, poor quality implementation of a filesystem.
- If the program or DLL name is followed by a comma and a number, this number points to a specific icon within the file.
- Expand one of these keys and you’ll find a sub-key named “shell” and very often one named “DefaultIcon”.
- The value of this key is the path to the program that is run to perform the action on the file.
- DefaultIcon, if present, contains the name of a program or DLL containing the icon that is used to represent files of this type in Explorer.
- When Windows executes the action it appends the name of the file to the command unless “%1” appears in the command string, in which case the file name is inserted at that point.
- HKEY_CURRENT_CONFIG is another mirror of a sub-branch of HKEY_LOCAL_MACHINE.
back when windows 95 introduced the registry, it was touted as the best way to store configs, compared with the windows 3.1 way of storing configs in .ini files…. I think you are ignoring one of the critical design requirements for Windows, just as for the IBM line of mainframes. These systems must work well, but must be very difficult to clone (reliably).
Parts are undocumented, seemingly to the Windows developers themselves (judging by the NT debug symbols that one paper has reproduced). Parts of the format waste space, while in other parts silly “optimizations” are made to save a handful of bytes (at the cost of making access much more complex). It’s quite popular to bash the Windows Registry in non-technical or lightly technical terms. I’ve just spent a couple of weeks reverse engineering the binary format completely for our hivex library and shell which now supports both reading and writing to the registry.
The problem with gconf, and the registry, is that their authors didn’t bother with strong use policies. They rejected old configurations files as inconsistent, but instead of defining conventions everyone should follow they proposed a mechanisms expecting conventions to emerge naturally. I was trying to suggest that it wasn’t enough to just provide an arbitrary dumping ground for data of any type, but that there must be a way to get information about the precise format of each entry. I was also thinking about the importance of tools to browse and clean the registry, which would require knowing how to display each piece of data to end users.
The Windows registry is one of several critical systems where you can never be quite sure you have cloned it all, as I’m sure you realize now. Yes, from the outside the engineering appears sub-optimal, but from the business perspective the architect has built a rather defensible barrier to their effective monopoly.