I wish they had the courage to get rid of the registry.
Also FYI the registry is stored in a single file.
The problem has always been that the data is shared system wide, even if it doesn't need to be. That and there is no easy way to clean up the registry if uninstalled programs did not do so properly.
The uninstalling procedure should clean the registry. "Uninstalling" is whatever the OS standardize as the correct procedure, Windows has one already, but it's reminiscent of the way people did packages by the time Linux software was distributed in tgz archives.
In Windows it's up to the app to clean up. It's not as great as *nix, but nobody is saying it was. Apt and friends just do the cleanup for the app, in a standardized way. If they miss something it's still there.
If you do have a use case where that matters, you can create a new user and apply permissions you want at a single key level. Available since windows 8 (or maybe before?)
And people who suggest SQL or another monstrous abstractions as an implementation need to take a step back and apply the idea of philosophical simplicity to their work. I honestly don't understand why people have this tendency to over engineer simple problems. I suppose it helps during review time.
People who sit back and say "replace it with text files/sqlite" don't really understand it or the problem it solves that well.
Using the actual file system brings in file system concerns - how do you handle registry transactions or concurrent updates?
1. https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
The registry is a database. There is a reason we use Postgres instead of flat files, and it is not people overdesigning things for review time.
And again, if you think the registry maps 1-1 to the file system you don't understand it. And that's fine. Just don't hate it because of that.
You also didn't mention concurrent access, or think about random code writing random completely invalid data into files, or consider how you would evolve the on disk format.
That sounds awful burdensome for a simple key-value api. Perhaps you could use some kind of service to shield clients from that complexity, and so you don't have one dumb program messing the entire registry up for everyone else.
That would be cool. You could call it the registry service.
After all, what is a filesystem if not a path to some data, papering over a complex subsystem?
Concurrent writes and type validation are way out of the picture here if you do that.
From Wikipedia: "The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry."
Are we still talking about a configuration archive or a production database for an application? That's when you have to start asking yourself: "is this a sane way to do things?" Because the more you argue for it, the less attractive it becomes as a solution for something that stores configuration data.
Oh yeah, that reminds me, you'd also need to handle subscribing to registry update notifications in this flat-file 'who needs anything other than text files' fantasy.
Again, just because you don't grok the problem space doesn't mean its empty.
Case in point: inotify.
Look. Yes you can hack together the registry using flat files, using FS notifications, using the insane transactional FS apis, magically working out how to handle concurrent writes etc and have every process that wants to interact with it implement this correctly.
But why. In every sense it is less clean, more complex and generally worse. Wasn't the idea to make it better and cleaner?
It is conceptually a bit simpler, however that doesn't mean it is better.
But hey, it's a one click thing to deploy a registry change to a fleet of 10,000 AD boxes, one that can change the configuration of the 1Password app as well as MS Word, and have it done reliably.
That's why it's better.
Why are you uninstalling software so often through AD? Not that it absolves this issue, but it's not common to have huge software churn like this. And hey, isolate the issue and push a registry change to every single machine in the network, instantly and consistently.
Random inconsistent locations, random inconsistent rules for inclusions and imports, Random ill-documented ad-hoc formats, no standard interfaces to add/remove/set config values, no ability to put ACLS on individual config entries, basically no way to export and re-import or auto-merge partial config, without at least screwing up whitespace and comments or risking duplicates, no ecosystem wide single 'source of truth' pattern.
They work, but they're not nice.
What the Windows Registry needs is a REST API.
That's not necessarily true.
In the 90's I worked at a large telco where we'd gotten good user roaming functionality along with package management using third party tools, for about 1600 applications, on Windows 3.
Uninstalling a package demonstrably left no remnants behind.
The migration to Windows 95 was troublesome partly because it was much harder for roaming users, but mostly the registry was much more difficult to manage - Office applications were notably impolite, with thousands of registry entries, many of which lingered after an uninstall, and no way to sanitise the registry other than reinstalling the OS.
If you're using a computer without a package management system I could see how you could be convinced config files are harder to manage (by hand) than an opaque blob that poorly hides its ugliness, but you'd have bigger problems.
shudders
Why would you want a networked API for stuff that should be internal to the machine?