Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

81–90 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#81

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 would actually be better if most of the data that applications store in the registry would instead live in simple text files in the AppData directory (which shouldn't be hidden by default). The registry should be restricted to Windows configuration data (like file types and their associated programs), and information that needs to be shared between installed applications.

Re: Why the Windows Registry sucks technically (2010)

#82

"2. Hello Microsoft programmers, a memory dump is not a file format" This is exactly how Office file formats worked in the good old times. Made things faster (no parsing).

> Made things faster (no parsing).

And simple. I parsed a wav file for the first time awhile ago and it was surprisingly refreshing how easy it was to parse. I just made some C structures in the format of the specification, and I could just read the file incrementally into different structs. This is way simpler than writing a parser and then marshalling data back and forth between an internal format and the configuration format.

Re: Why the Windows Registry sucks technically (2010)

#83

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…

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 can respond in version 4 format.

With a service it doesn't matter if things are stored as a single sqlite DB or as multiple files.

Re: Why the Windows Registry sucks technically (2010)

#84

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…

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.

It's interesting though that "boring UNIX" has survived, while most non-UNIX operating systems have gone the way of the Dodo ;)

Re: Why the Windows Registry sucks technically (2010)

#85
I don't understand how people figure out what registry entries to make out of the ether for certain changes.

I don't know why most programs have an in-program settings menu, an external settings.json or something similar, and then registry entries to configure similar things.

I don't know why Windows has almost 0 policing about programs editing the registry. If you uninstall a program, why is it so hard to remove all entries? Why do entries usually from deleted programs sometimes turn into random strings of characters?

The whole thing reminds me of developers installing to %APPDATA% without my agreement, because they want to circumvent getting admin permissions. That's the whole point of admin permissions. Also if I don't want everything installed on my C drive, because it's a smaller sized SSD, I'm just out of luck.

Re: Why the Windows Registry sucks technically (2010)

#86

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…

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…

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.

Re: Why the Windows Registry sucks technically (2010)

#87

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…

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…

Is this sarcastic?

I mean, the versioning part sounds good, but JSON like request?

I do believe people don't know what inefficient/efficient a system can be depending on the data format they are using.

Re: Why the Windows Registry sucks technically (2010)

#88

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…

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.

The people at nixos and guix are doing it differently. No longer is the configurarion just state in files, scattered who knows where that cannot be understood fully by anyone. Insteady everything is defined centrally and then neatly versioned and managed by the system. If you think the unix way of throwing files in a directory sucks, check them out!
Post reply on HN