Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the Windows Registry sucks technically (2010)

rwmj.wordpress.com

Post reply on HN
Print view View original

91–100 of 342 posts

Re: Why the Windows Registry sucks technically (2010)

#91

Post by tauroid »

samanator wrote: post #72
Someone1234 wrote: post #9

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

For those looking for a more up to date alternative, with a non-hardcoded DB file path, try https://github.com/greenbender/sqlfs (not affiliated, just had a look in this area a few weeks ago)

Re: Why the Windows Registry sucks technically (2010)

#92

Post by rwmj »

magicalhippo wrote: post #78
rwmj wrote: post #54

Earlier quoted context omitted.

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

The first thing to know about Microsoft documentation is it's almost always wrong.

Re: Why the Windows Registry sucks technically (2010)

#93

Post by Neil44 »

bgro wrote: post #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…

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

Experience, trial and error, documentation, reverse engineering... you can use something like ntregmon to see everything a program touches in the registry and work from there. The quantity can be overwhealming and when you finally whittle it down you realise what you want isn't there, it was in a .ini in a random 90's file path the whole time.

Re: Why the Windows Registry sucks technically (2010)

#94

Post by npteljes »

bgro wrote: post #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…

You can move %appdata% - kind of:

https://superuser.com/questions/1250288/can-i-move-my-appdat...

I don't understand the rest, to be honest. For many years, the mess was even larger, because config files were coupled with the software itself.

Re: Why the Windows Registry sucks technically (2010)

#95

Post by deelowe »

jbverschoor wrote: post #60
lelanthran wrote: post #36

Earlier quoted context omitted.

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

I can’t and shouldn’t be able to write to /etc as an ordinary or guest user. Er-readying values isn’t done usually with apps. You can get corrupted files if two instances fight for the same file. If that’s your thing, please use mongo. Also, please provide support to all the users. Lastly, if you messed up certain configuration or data files, your system won’t boot either on ANY system. Sounds like you’re just one of…

> I can’t and shouldn’t be able to write to /etc as an ordinary or guest user.

You're right, you shouldn't. If you are able to, your distro is very odd and I'd recommend seeking a new one.

> Sounds like you’re just one of many anti-windows people, exactly what was pointed out about people bashing the registry.

There's no need to attack people.

Re: Why the Windows Registry sucks technically (2010)

#99

Post by ElectricalUnion »

mikepurvis wrote: post #75
indymike wrote: post #50

Earlier quoted context omitted.

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

Most Linux GUI apps either litter your home folder with dotfiles, dotfolders (both disgusting) or they follow XDG Base Directory specifications and place configurations in ${XDG_CONFIG_HOME:-${HOME}/.config}

Re: Why the Windows Registry sucks technically (2010)

#100

Post by cycomanic »

mikepurvis wrote: post #75
indymike wrote: post #50

Earlier quoted context omitted.

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

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

What do you mean? You are mixing multiple things, most of var and lib are also only root writable (unless tied to a specific user). For GUI application you generally end up with a system where etc holds the system defaults and user configuration is in $XDG_USER_CONFIG which defaults to $HOME/.config. This is the case for the vast majority (>90%) of GUI applications.

If we're are talking state, that typically ends up $HOME/.cache (if it should be temporary) or $HOME/.local/var (if it should be persistent). There are also XDG variables for these but I forgot them at the moment.

So can you elaborate what you mean with your perceived problem?

Post reply on HN