Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

71–80 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#71

Earlier quoted context omitted.

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

I probably miss something then. The article also states that it is not a database.

It is a long standing debate, see this thread:

https://news.ycombinator.com/item?id=27939728

basically it has some characteristics of a database and some characteristics of a filesystem (and a filesystem is actually a particular form of database), not entirely unlike the "over or under":

https://en.wikipedia.org/wiki/Toilet_paper_orientation

it is an endless one, both views have their merits (but it is "over" and a filesystem ;))

Re: Why the Windows Registry sucks technically (2010)

#72

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…

Maybe there isn't a database engine that explicitly supports file system data structures, but you could implement a filesystem in the application layer using SQLite as a storage mechanism.

Here's an example of someone doing that very thing.

https://github.com/guardianproject/libsqlfs

Re: Why the Windows Registry sucks technically (2010)

#73

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…

No post body was provided.

Re: Why the Windows Registry sucks technically (2010)

#74

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…

Heierarcical databases support the registry format. But they are popular in the 70s?

Re: Why the Windows Registry sucks technically (2010)

#75

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…

> Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that has survived in time because text files are still text files. It always seems like registries are trying to solve three different problems: configuration, status and process shared state. Registries seem to work poorly compared to text files for configuration, and work somewhat well for some level of sh…

The biggest issue with etc is that it's owned by root and therefore read only from the application's point of view. So, a great fit for sysadmin-managed configuration, not so great for applications that are GUI-configurable. You end up with a tiered approach of defaults in lib, and cascaded overrides in etc and var.

Re: Why the Windows Registry sucks technically (2010)

#76
post #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 Windo…

[deleted]

Re: Why the Windows Registry sucks technically (2010)

#77
post #29

It is easy to be critical of Microsoft and many of their decisions until you reflect on the reality that they have provided the software that has been running billions of computers world-wide for almost four decades. And they have done this with an astounding level of software and hardware compatibility across time, devices and technologies. This is critical to understand before pointing at anything MS and being crit…

And it is "of its time" - it appeared in Windows 3.1 which was 1992. Which was the era of floppy disks as well.

Well, no, the registry in Windows 3.1/3.11 was vastly different in format and at the time it was actually a single file, reg.dat:

https://devblogs.microsoft.com/oldnewthing/20120521-00/?p=75...

Re: Why the Windows Registry sucks technically (2010)

#78
post #54
post #32

Earlier quoted context omitted.

> 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 Windo…

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? I did a bit of experimentation on this too and we think it has a heuristic to guess encodings of strings. (Which to be fair isn't a terrible idea - it's very easy and almost entirely reliable to determine if a string is ASCII/UTF-8 or UTF-16LE which are the major encodings found.)

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 buffer pointed to by pvData.

[1]: https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf...

Re: Why the Windows Registry sucks technically (2010)

#79

Earlier quoted context omitted.

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 isn’t a single file. There are multiple “hives” to the registry. There is at a minimum the SECURITY, SAM, SYSTEM and BCD “hives” that are all individual files on disk. Additionally, individual UWP apps can have their own isolated hive if need be.

Related documentation: https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis...

Re: Why the Windows Registry sucks technically (2010)

#80
post #14

>Hello Microsoft programmers, a memory dump is not a file format Wait until you see the Office formats without the extra x in the extension.

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

They were formats designed to be fast on floppy drives which were major storage format at the time, and most importantly, designed as "work in progress" format.

For interchange, you were supposed to use other formats - for example RTF with Word, which was kept in sync with DOC capabilities all the way to Word 2003 which was the last version that used DOC (2007 uses DOCX and no longer maintains DOC+RTF combo in sync with internal features). However, saving back the file if you did small change in large RTF file took ages in comparison.

Post reply on HN