[eterm]

Indeed, the registry is actually a good feature, it's a configuration database rather than relying on flat files as in the "just go to /etc/<package>/<package>.config or /home/<user>/.package/<package>.config" of the linux world.

The problem is that when it was first introduced in windows 95 the registry would easily and often corrupt causing many issues so some people still associate the registry with being a bad design, when it was actually just a bad implementation of a good design.

[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"

[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.

[zaarn]

We live in a world where MongoDB is at the butt-end of all Database and ACID jokes.

But the award should go the Windows Registry, a Key-Value store that combines the drawbacks of a half-assed filesystem with the advantages of piping your database to /dev/null.

A Database would be capable of using an index to traverse all the keys. The Registry does a linear lookup at each pathnode.

There is a good blogpost [https://rwmj.wordpress.com/2010/02/18/why-the-windows-regist...] that details the insanity of a database that managed to be worse than MongoDB at the lowest level of jokes before MongoDB was even invented.

[kalleboo]

I think the macOS User Defaults system is still my favorite config system. Unified api (`defaults` and NSUserDefaults), but stored in user-editable (and easily cleaned up) files with standardized naming and formatting. It's not perfect (kooky and unwieldy XML syntax, no standard equivalent of conf.d), but it solves the pain points I've seen with the Windows Registry (monolithic inscrutable database) and unix commands (random config files each with their own custom place and format)

[krylon]

I think the major problem with the registry - besides being obscure - is that it can grow really slow as it fills up, and many programs do not clean up their registry data when being uninstalled. I think this is one of the major factors why Windows grows so slow after a couple of years on machines where lots of software is being installed and uninstalled.

[mappu]

Most Linux programs don't remove their files from /etc/, ~/.local, ~/.config on uninstall either.

[krylon]

Granted, but the presence of those files does not slow down the system significantly. With leftover registry keys, you pay the price until you install the system from scratch.

(Windows might have improved the registry handling code since Windows 95/98, I think it's not quite as bad these days... but that might also have to due with computers being much faster than 20 years ago.)

[nitrogen]

That's what the purge option to apt/dpkg is for.

[anothergoogler]

GNOME provides a registry called gconf, now dconf (binary format). Many applications outside of the GNOME project use this registry.

[Hello71]

if it's trying to be a database, it's doing a terrible job. all the problems of not being files (can you do "find HKEY_CURRENT_USER -name mypackage" to see what the uninstaller left behind?) with none of the benefits of a database (ACID).

[krylon]

When they were working on Windows 7, Microsoft tried to be more open about the development process in order to repair some of the damage Vista had done. So one day, I came across this video, an interview of a few Windows developers.

At one point, the person doing the interview asks, "So, what do you guys think of the Registry?". Awkward silence, followed by uncomfortable laughter. Finally, one of the programmers says, "I think it's fair to say it was far more [widely used] than any of its designers had anticipated."

(Quoting from memory from a video I saw once, ~10 years ago, so the wording might not be perfectly accurate, but that's how I remember it.)

[mappu]

> can you do "find HKEY_CURRENT_USER -name mypackage"

Powershell comes with a kind of FUSE mount for the registry:

    PS C:\> Set-Location HKCU:
    PS HKCU:\> Get-ChildItem -Recurse | where-object { $_.Name -match "HeidiSQL" }

[Slackwise]

Or for those who come from Unixland and see way too much typing, PowerShell has aliases that make this much shorter:

    cd HKCU:
    ls -r -i *HeidiSQL*

Or if you really want to use the match operator, regex, or other expression, you can still pipe it through the Where-Object alias:

    ls -r | ? {$_.Name -match "HeidiSQL"}

[joeyaiello]

Just to make sure everyone on HN knows you can get real pithy with PowerShell, this also works:

  PS C:\> cd hkcu:
  PS HKCU:\> ls -r | ? name -m 'HeidiSQL'

[Analemma_]

> with none of the benefits of a database (ACID)

This is not correct, Windows Registry updates are atomic and transactional. There may be other problems with the registry model, but it is a "real" database.

[krylon]

ACID means more than atomic updates, though. To be ACID-compliant, you'd have to be able to group several changes to the registry and have them take effect either all at once or not at all.

[Const-me]

> To be ACID-compliant, you'd have to be able to group several changes to the registry and have them take effect either all at once or not at all.

You mean transactions? Windows registry supports them since Vista when they added Kernel Transaction Manager: https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...

See CreateTransaction, RegCreateKeyTransacted, RegOpenKeyTransacted, CommitTransaction[Async], RollbackTransaction[Async] APIs.

[krylon]

I stand corrected. Good to know, thank you!

[Const-me]

To be fair, I’ve never used KTM in my apps.

In cases when I need to write several values atomically (e.g. in a program with persistent window positions, after user moved a window I want to write all 4 coordinates of the rectangle), I just keep them in a single value, either string or binary. Even without KTM, registry API already guarantees value writes are atomic.

[eterm]

A word for that is transactional.

[fulafel]

It's implied by the I (isolation).

[ksk]

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

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