Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

31–40 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#31
post #24

Earlier quoted context omitted.

> The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". Every application comes up with its own format. Parsing that file is application-specific. Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that ha…

Is there any "way" at all that doesn't suck though? Not having "a way" in this sense is more like a feature, a single source of truth works well if it really is treated as such by all actors. Configurations under unix are a mixture of stdin, config files, env variables and bespoke solutions. Under Windows, you have all of the above and on top of that the registry. Any attempt at a solution in this regard risks being…

On a more philosophical level, the Unix convention is the "liberal" one, giving application writers more freedoms. Liberty enables more flexible applications and more chaos at the same time. A highly structured approach might be beneficial in the short run, but it might prove to be burdening beyond its due date.

Re: Why the Windows Registry sucks technically (2010)

#32

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…

> and there's no format agnostic API to access that information (you can open it, but can you understand it?).

One of the critiques in this article is that, because you have to know/guess/assume what encoding is used for various strings, there isn’t one for the registry, either.

If so, both approaches suffer from that (but Unix a bit more because it tends to store multiple items under a file system ‘key’, while Windows programs rarely store multiple items under a single registry key)

I do wonder what RegEdit.exe does here. Does it infer encoding, have a long list of key-to-encoding mappings, or a combination of the two?

Re: Why the Windows Registry sucks technically (2010)

#33
post #11

Earlier quoted context omitted.

Actually the Registry is not a single file, it is a set of files virtually assembled into a single "object" that has many points in common with both a database and a filesystem. Personally I see it more like a filesystem, with some striking resemblance to NTFS.

It is a single file to the underlying filesystem. Yes it reimplements a filesystem, I already said that in the comment you are replying to.

It's far from being a single file. Registry is split to hives. Besides that, each hive is a bunch of files (actual hive, a pair of integrity logs - which was just one log file before Vista - and hell knows what else, some KTM-related stuff I presume):

   > dir /a C:\Windows\System32\config
   ...
   29.07.2022  12:33        44 040 192 COMPONENTS
   21.11.2010  10:21             1 024 COMPONENTS.LOG
   29.07.2022  12:33           262 144 COMPONENTS.LOG1
   14.07.2009  05:34                 0 COMPONENTS.LOG2
   29.07.2022  12:33            65 536 COMPONENTS{016888b9-6c6f-11de-8d1d001e0bcde3ec}.TM.blf
   06.03.2021  21:44           524 288 COMPONENTS{016888b9-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000001.regtrans-ms
   29.07.2022  12:33           524 288 COMPONENTS{016888b9-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000002.regtrans-ms

Re: Why the Windows Registry sucks technically (2010)

#34

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 problem of removing applications together with their configurations is trivially solved in the various Linux-based systems where any software package is installed only inside a private directory. Any files that would be expected to be in shared directories like /usr/bin, /usr/lib or /etc, are replaced by symbolic links. Except for symbolic links, the installation of a package must not change anything outside its…

>the various Linux-based systems where any software package is installed only inside a private directory

Which are these? I assume Qubes OS sidesteps the problem entirely... NixOS?

Re: Why the Windows Registry sucks technically (2010)

#35

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 UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". Every application comes up with its own format. Parsing that file is application-specific. Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that ha…

I hate this fanatical love of the UNIX way. I really hate that as of today Windows is the only non UNIX OS. I trully believe that this fact set us back. No more exciting new OSes only boring unix.

Re: Why the Windows Registry sucks technically (2010)

#36

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 UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". Every application comes up with its own format. Parsing that file is application-specific. Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that ha…

> Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc".

So? The registry doesn't have much of a way either - the actual fields are simply a loose convention.

> Every application comes up with its own format.

Same with Windows applications - one application might store an IP address as a dotted-octet string, another might store it as a single 32 bit integer.

> Parsing that file is application-specific.

Same for Windows applications; the subtree for any application is very specific to that application and almost always differs from the subtree for other applications.

> Updating a value in a text file means re-writing the whole file again.

Not a problem, when it means that breaking a value in a text file breaks only that one application. Break the registry almost always breaks something else, if not the entire system.

I'm not saying files in /etc aren't without their problems, I'm saying that all /etc problems are already present in the registry, but the registry adds a few more of its own.

Re: Why the Windows Registry sucks technically (2010)

#37
post #23
post #14

Earlier quoted context omitted.

That was a deliberate attempt to make it impossible for competitors to read and write their format wasn’t it?

I don't know the exact year that file format was made, but you had to think about performance more than wasting so much memory and cpu cycles to have a fancy file format, no? Ofcourse that era Microsoft tools didn't think much about interoperability outside of Microsoft ecosystem. But to me it seems that them having some XML based file format at that time would be silly and have disadvantages. XML actually was starte…

Agree. I think most software of the era did that kind of thing.

Most of it wasn’t popular enough and/or got abandoned soon enough for ‘the internet’ to notice, though.

If your software runs in 256kB, writing to a floppy disk, you pack your data structures, use bit fields where possible, and you’re not going to waste CPU time, RAM and disk space to write a format that’s easy to understand and extend.

(Of course, they extended it, anyways, as everybody would)

Re: Why the Windows Registry sucks technically (2010)

#38
post #20

> This is a far cry from /etc/progname.conf in Linux. Some of these arguments are not really in good faith. First, this isn't a technical issue with the registry, but with how it's been used over the years and never "refactored" - a distinct issue. Second, I dare you to run "ls /etc" and claim it's not a mess... Besides, most of the post is how anyone with a text editor and admin rights can bork/hack the machine. As…

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 engineer these file formats.

Of course, most important files contain whitespace separated lines of configuration of which the meaning is only clear if you read the comments above it (cron, fstab, crypttab) or secretly bash scripts (GRUB config and many other files in /etc/default).

Then there's user configuration stuff. Sure, HKLM vs HKCU is kind of weird, but the user configuration structure in the Linux home directory is an argument against intelligent design. ~/.config, ~/.programname, ~/.local or ~/snap//current/? Roll the dice and find out! You may be able to find the setting you're looking for in the DConf Editor but if you can't find it there, grep and prayer is your best bet.

The Windows registry may be the result of a flawed execution, but I'll take it over the mess in Linux any day. Sadly, the registry has fallen out of fashion in Windows so now managing random configuration files somewhere in %USERPROFILE% (if you're lucky and the programmer hasn't hardcoded C:\Users\ as a path) just like on Linux. By the way, who needs the "hidden" FS flag anyway? Just start the filename with a period and pretend the ls-bug-dressed-up-as-a-feature for hiding files and folders is a standard every platform sticks to!

Re: Why the Windows Registry sucks technically (2010)

#39
A 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 in the first place, to save space.

Re: Why the Windows Registry sucks technically (2010)

#40

>The Registry binary format has all the aspects of a filesystem: things corresponding to directories, inodes, extended attributes etc. Like? Always thought it was an hierarchical database.

>> The Registry binary format has all the aspects of a filesystem: things corresponding to directories, inodes, extended attributes etc.

> Like? Always thought it was an hierarchical database.

A filesystem is a hierarchical database.

Post reply on HN