[jacquesm]

The windows registry is absolutely terrible at its job. The namespace is polluted from day #1 after installation and this only gets worse as a box gets older. The number of places the same key could appear are baffling and you never really knew when you had exterminated the last instance of HKEYsomethingorother to achieve the desired effect.

[derefr]

Yes, but this is because third-party developers don't know what the hell they're doing in regards to the Registry. The Registry was never supposed to be a persistent storage location for application configuration data. INI files were doing very well when the Registry was created, and Windows still used INI files for most things even as it exposed some things in the registry. The INI API was the official application configuration API. (And today, application manifests are the official configuration API: essentially INIs in XML.)

No, actually, the Registry was supposed to effectively be the place to find and manipulate the same sort of data you'd get from Linux pseudo-filesystems. HKEY_CURRENT_CONFIG is essentially Linux's /sys, for example. HKEY_LOCAL_MACHINE\System\CurrentControlSet is equivalent to Linux's /dev. Etc.

The nice thing is that each Registry hive could be implemented with a different backend, and thus impose its own constraints on the format of the data. HKEY_CLASSES_ROOT, for example, could just be an interface into the shell's filetype database, and require that the data you put in there conform to the columns of that database, and their types.

HKEY_LOCAL_MACHINE\Software, though, was where things went wrong. The HKLM hive, and especially the Software key under it, was essentially a sort of... asynchronous RPC. It was there to allow system daemons to have their configuration changed at runtime, without needing to be restarted. They could just re-read Registry keys directly each time they do something, and so writing to the HKLM keys would change what happens as soon as their next message loop.

But HKLM was also persisted as its own free-floating database file, just because it was much more convenient to write the key once, rather than having to write it once for immediate runtime effect and then another time to an INI file for persistence (like how, say, Linux's sysctl(2) + sysctl.conf(5) work.)

And third-party developers came along and noticed that they could just write whatever they liked into HKLM under some random key (at least during install-time in NT; or all the time in 9x), and then be able to get it back later. So they did. Oops.

Everything since then has been patches to try to fix the problem this caused (because, from Microsoft's perspective, you do still have to keep these programs working, despite their faux pas.) HKEY_CURRENT_USER was created because applications were just writing their config system-globally to HKLM and thus a multiuser system would have each copy of the software retaining its config from other users' sessions. (It was easier to get them to change the target hive, than to get them to rewrite their code to use INI files for config.)

[ksk]

The job of the registry is to be a reliable structured storage with access control and other features. It is not responsible for the things that go into itself.

Here is the API.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...

Could you point out which one of these doesn't work as intended?

[jacquesm]

If you put together a structure like that and leave the sordid details up to the implementer and you supply a mostly confusing example as the set shipped with the OS, and subsequently mess it up even further with your own application installs you own the mess.

[nitrogen]

An upvote isn't always enough, so I just want to say I support your holistic view of engineering and find the "not a bug, not my problem" approach detrimental to the broader success and acceptance of technology in society.

[ksk]

I'm unable to extract anything specific from your comments. Are you still talking about the registry or about something else? Its cathartic to vent, but the registry is not the source of your frustration.

[thomastjeffery]

That's because it's about the bigger picture.

[ksk]

Okay.. call me small-picture-minded but I much rather prefer - "I press a button M and Feature X doesn't work when I choose option Y" - over "Feature X is terrible at its job"

[thomastjeffery]

When a platform is purposefully incompatible with another platform, that effectively devalues the other platform for users.

Unless you are totally convinced that your chosen platform is the only one that matters, this behavior is a problem.

[jacquesm]

> I'm unable to extract anything specific from your comments.

That's ok.

[Too]

The problem is not that they don't work as intended, the problem is what is intended. You can't just throw application developers an API like a system wide key value store and expect the whole worlds ecosystem of applications to organize itself around it. Android and iOS solve this much better by sandboxing application settings within the app. Uninstalling the app is guaranteed to remove any traces of it (unless you give access to "all files and photos"), whereas on windows there is always some remains.

[ksk]

Its just a database. Using the registry is not a requirement for any app. They can store their configuration in a text file, they can store it in the cloud, they can do whatever they want, they can even create a C:\etc and store it there :)

Sure, there exist badly behaving apps that don't clean up after themselves when they're uninstalled. Windows gives apps the freedom to choose their own method of installation, but some vendors abuse those freedoms. I don't quite know what the OS is supposed to do about that. Windows already does an insane amount of work trying to keep buggy apps running, something that macOS or iOS or Android or Linux don't. The fundamental goal of any consumer OS should be making sure that the software a user purchased continues to work.

>Android and iOS solve this much better by sandboxing application settings within the app.

So, multiple users on a device = separate settings = multiple app installs? That might work OK for consumer devices, but won't really fly in the IT world.