I really appreciate when people use technical facts to criticize something, like with this. It is a well written take-down of the implementation of the Windows Registry as of both today and 2010. I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a da…
The concept of a system-wide hierarchical key-value store is actually very useful is some environments. I had to develop one some time ago [1] for an embedded system, since is super useful to have a single point of truth/configuration/state, if every application agrees on using it (which is the case in such systems were every application is known in advance and developed in house) [1] https://github.com/debevv/camell…
Why the Windows Registry sucks technically (2010)
251–260 of 342 posts
Re: Why the Windows Registry sucks technically (2010)
#252I really appreciate when people use technical facts to criticize something, like with this. It is a well written take-down of the implementation of the Windows Registry as of both today and 2010. I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a da…
"The format is... endian-specific." Wasn't there a SPARC port of Windows? Did it run on any other big-endian machines? Were the MIPS and POWER ports little-endian? In any case, I can see why Microsoft paid SQLite for a custom set of features.
Re: Why the Windows Registry sucks technically (2010)
#253Earlier quoted context omitted.
You can do everything you describe with a regular function call. Introducing an unnecessary service for something as trivial as config management is even worse than the broken Registry status quo.
In theory all we need is a libconfig with a standardized interface and distro specific implementations. There would be two use cases, storing hierarchical/tree like data aka JSON, YAML, etc and arbitrary graph like data with complex references. The same could be done with the shell. libcli would be called to parse the command line arguments and your program will have an entry point that receives the parsed data. libc…
Re: Why the Windows Registry sucks technically (2010)
#254Earlier quoted context omitted.
If I was to reimplement it, I would not let any app read the DB directly. Instead I would make an HTTP like interface where you talk to a service that provides the get/set functionality and which always use a text format like an extended JSON with native support for date, int32, etc. This also enabled much easier and better backwards compability as you can specify app-version in the requests, so a version 5 server ca…
The article's complaints about the format being undocumented are ill-founded, because Microsoft repeatedly tells developers not to read the registry directly, and call the exquisitely documented functions instead. The applications that didn't listen to Microsoft and depended on particular features are most of why it hasn't updated to modern standards in the first place.
Re: Why the Windows Registry sucks technically (2010)
#255Earlier quoted context omitted.
Based on the documentation[1], it seems clear that strings are stored in Unicode (which should be UTF-16LE). If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, and the ANSI version of this function is used (either by explicitly calling RegGetValueA or by not defining UNICODE before including the Windows.h file), this function converts the stored Unicode string to an ANSI string before copying it to the b…
The first thing to know about Microsoft documentation is it's almost always wrong.
Anyway, where in the hivex code do you handle these non-Unicode encoded REG_SZ values?
Btw, the comment for hivex_value_multiple_strings is based on a mistaken interpretation of the documentation. There's nothing contradictory to what MoveFileEx does[1], it simply has a list with a single entry in the case of deletions, and a list with two entries in case of renames.
The REG_MULTI_SZ documentation[2] just points out, correctly, that you can't have a zero-length string within a list of other strings (ie with at least one non-empty string after it). This is of course obvious and hence redundant, but they highlight it for novice programmers.
[1]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...
[2]: https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis...
Re: Why the Windows Registry sucks technically (2010)
#256A point being overlooked by article and commenters: the records in the registry probably use in the order of 10-100 bytes each, while every actual file takes up at least around 1024 (EDIT: maybe more like 4096?) bytes. Putting tiny 'files' into a special format is a no-brainer on the older computers that existed when the Registry was first created. I am assuming this was one of the motivations to create the Registry…
That overhead is not intrinsic to the concept of a filesystem. If you asked someone to design a filesystem specifically to store short strings they could easily come up with a low-overhead design while preserving the other advantages of real filesystems.
Re: Why the Windows Registry sucks technically (2010)
#257https://news.ycombinator.com/item?id=1134307 (2010)
https://news.ycombinator.com/item?id=32249845#32269623
Also mentioned tools for working directly with registry files from Linux (including within VMs).
Re: Why the Windows Registry sucks technically (2010)
#258Earlier quoted context omitted.
It's a great thing about etc. If your application `foobar` wants to write something to /etc and doesn't have root privileges (which it probably shouldn't), create a subdirectory /etc/foobar with owner `foobar:foober`, and write there all you want. Many applications do that and it works fine.
I have not seen any applications creating a user with the applications name. How can one avoid a naming conflict? Kate (a text editor) might be installed on a system by Kate (a person). What I have noticed however is that there are daemons running as root and is used as a "middle man" whenever an application running as a normal user needs some extra privilege.
Re: Why the Windows Registry sucks technically (2010)
#259I spent 15 years maintaining and developing a Windows application and I utterly despised interacting with the registry. It was a nightmare trying to find where a specific key should be written, what the format was meant to be, and browsing the thing with regedit was horrific. And then from a code point of view, win32 APIs for manipulating it were incredibly clunky. I was forever worried I'd accidentally corrupt the whole thing somehow and windows wouldn't boot any more.
Meanwhile on linux I think from a technical point of view, slamming random bits of text into files scattered in random places all throughout the file system in undefined formats is a terrible idea. And I love it. I understand the whole linux configuration and internals so much better because I can browse around /etc and see how every piece of the system is set up.
Re: Why the Windows Registry sucks technically (2010)
#260Earlier quoted context omitted.
I love editing files in /etc ending in conf! Some are pseudo-INI (OpenSSL), some are pseudo-XML (Apache2 and friends), some are some kind of unholy amalgamation between C and YAML (nginx, dhcp daemons), others are some kind of TOML derivative (systemd, NetworkManager) and there's also some diet JSON in there! Netplan uses YAML, of course, though JSON will probably also parse. It's always a fun adventure to reverse en…
> I love editing files in /etc ending in conf! Some are pseudo-INI (OpenSSL), some are pseudo-XML (Apache2 and friends), some are some kind of unholy amalgamation between C and YAML (nginx, dhcp daemons), others are some kind of TOML derivative (systemd, NetworkManager) and there's also some diet JSON in there! Netplan uses YAML, of course, though JSON will probably also parse. It's always a fun adventure to reverse…
I remember struggling to get some open source VPN package to work right. I swear I've read through the manuals three or four times but it just wouldn't work and the error messages were meaningless. I know most of the obscure formats now out of experience, but it's still not great. DNS BIND configuration and zones (and the accompanying AppArmor configuration) also caused me more trouble than necessary. Configuring and debugging inetd configuration was also something I never hope to do again.
> Well there is "man fstab", "man 5 cron" etc
Of course there is, but those aren't exactly light reading. It's not that the formats are difficult to find, it's that there's no consistency to the formats themselves with nameless columns that you need to figure out by reading several paragraphs of text.
> Which program saves configuration inside ~.local? I'm not aware of any and they generally should not. Also adding adding snap to that list is a bit besides the point, I don't think containers typically save their configuration in the registry either?
In my ~/.local/etc I see fish and bash_completion.d, for example. I don't know what programs created those, but they're there. I see some PipeWire files in ~/.local/state. ~/.local/share contains many files ending in ".conf" (most of them Flatpak, but also Kodi and GnuPG). I prefer them stuffing their config in .local rather than ignoring XDG, though. IMO Snap fits the list perfectly because it's not sold as "containers", it's sold as an "app store" even though it's focused on GUI containers. And I'm still mad about Snap not even bothering to use a capital letter in their home directory name.
I like dconf in that most settings are actually documented in context. They're searchable, use a standard format, and have structure. The ability to distinguish default values from custom settings is also very nice. IMO it's the Windows Registry but with a good editor and an even worse API.
> So how do you know what registry keys to change to achieve a certain configuration
Most of the time, I can use the find tool to find exactly what I need in the registry. I barely need to touch it anyway since most Windows settings are configurable from the GUI. Sure, it's certainly not the best config management system, but it's design is much better than the hodgepodge of configuration files unrelated systems use.
I admit that on disk, the Windows registry format is atrocious. However, the concept of a single, unified, backuppable, remotely manageable configuration system is just much better than "let's stuff some files in /etc and let people find out by making them go through our docs". I don't know where to look for config files on Linux, on most Windows tools I at least know what program I need to open to edit the configuration. I'd like DConf or at least XDG to get used more often because IMO the Linux ecosystem is the worst of two options.