> The Registry sounds like a great concept but it's the worst architectural decision Microsoft ever made for Windows. I think the problem wasn't so much the id

> The Registry sounds like a great concept but it's the worst architectural decision Microsoft ever made for Windows. I think the problem wasn't so much the idea itself, it is just that the implementation left a lot to be desired. A better implementation of the same idea could have been much more successful. The registry could have come with a schema, whereby each key has a class defining what values it is allowed to have. I think Microsoft may have actually had some plans to do that, because every registry key has a "class" (lpClass parameter of RegCreateKeyExW) – however, few registry keys have the class field set, and almost no software pays any attention to it – suggesting that whatever Microsoft was planning with respect to a registry schema never came to pass. There could have been a "schema hive" containing class/attribute definitions, and then any attempt to set a key/value on a schema-enforced key would be validated against the schema hive. If keys had an enforced schema, the registry could be self-documenting – the class and attribute definitions could have a "description" value explaining what each is for. I suppose Microsoft couldn't force third parties to write meaningful descriptions, but they could have set a positive example. They could also have had a tool to auto-generate schema documentation (in HTML or RTF or whatever) from the descriptions in the registry schema. They could have implemented something like a "foreign key" – a link type which will not let you delete the target while other keys have values pointing to it. (Not the existing REG_LINK which is much more limited; REG_SMART_LINK maybe?) This would likely need some kind of "backlink" index for fast retrieval of back-references. Maybe each key could have a "virtual attribute" which contains a list (REG_SMART_LINK_LIST) of backlinks. The schema could specify what are the allowed target types for any link attribute. They could have a package database in the registry, and enforce that every registry key is owned by a package. Uninstalling a package automatically removes all the keys it owns. They could have shipped with an IFS which exposes the registry as a pseudo-filesystem, which would have made it easier to manipulate. (Cygwin kind of does this with /proc/registry, and PowerShell has something similar, but it would have been better as a proper filesystem which appears like any other.) It could even expose the registry data as JSON or XML files, dynamically generated at runtime. \\registry\HKEY_LOCAL_MACHINE\Foo\Bar\Baz\__REGDATA__.json could be a JSON file containing the values of the HKEY_LOCAL_MACHINE\Foo\Bar\Baz registry key. If you write to that file, it could parse the JSON you write and update the values appropriately. > The unix model of plain text files for configuration is a much better idea than a Registry. I actually don't like that model. You end up with text files littered all over the place. Automating configuration is a mess because every app has a different config syntax. It is a flawed model too, just with a different set of flaws. > The Registry is the reason why you need an installer instead of being able to drop application files into a directory and run them. Not really. An application can be designed to not require any registry keys, and so if all its registry keys are missing it just uses sensible defaults. Or an application can be defined to check for its required keys at every startup and create them if they are missing. Microsoft could have defined a way for an application to embed a small registry hive in its EXE. When launching the EXE, it would check if those keys exist in the registry, and automatically load them. In Microsoft's defence, the Registry was designed in the early 1990s (it first shipped in Windows 3.1 in 1992), and a lot of the ideas I am proposing may have had too high a performance cost for the limited machines of the early 1990s, or relied on technologies or ideas which people hadn't thought of yet.