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…
Why the Windows Registry sucks technically (2010)
81–90 of 342 posts
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).
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)
#83I 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…
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)
#84Earlier 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.
Re: Why the Windows Registry sucks technically (2010)
#85I 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)
#86I 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…
Re: Why the Windows Registry sucks technically (2010)
#87I 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…
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)
#88Earlier 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.