And they even made the setting easily accessible, just hit [HKEY_CURRENT_USER\Software\Microsoft\Notepad] and change some registry key
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.
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.)
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?
Unless you are totally convinced that your chosen platform is the only one that matters, this behavior is a problem.
That's ok.
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.
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.
(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.)
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.)
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" } cd HKCU:
ls -r -i *HeidiSQL*
ls -r | ? {$_.Name -match "HeidiSQL"} PS C:\> cd hkcu:
PS HKCU:\> ls -r | ? name -m 'HeidiSQL'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.
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.
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.
Could you point out which of these doesn't work as intended?
I can only assume that requiring an ops team to change a setting in a basic text editor is pretty standard in the Windows world, too?