[shawnz]

Certainly there is a lot of legacy with the registry, but how would any of these issues be improved by moving to a file based config? All these issues could still exist under that model, and there would be new issues too.

Like for example, you already point out how the type system in the registry is very limited. But isn't the filesystem even worse? Everything there is binary blobs with no types at all. So how does that improve things?

It seems like your complains don't really have to do with the "directory" structure of the registry much, so I don't think moving to a file based model would really change anything. You'd just end up with the same legacy issues, but spread across more files.

Finally, AppData wasn't introduced with Vista, but rather it's always been there if applications need to store file-based data rather than individual configuration values. That is not a new or improved way of doing things as you seem to imply in the post.

[rwmj]

The problem with hive is that the type has to be set correctly yet several types have no established meaning. For example it's totally random whether a number will be stored in binary with type DWORD or stored as a string (with who knows what type and encoding). However store it in a different way when writing to the registry and Windows or whatever app wants to read that field will break. In a way it's worse than if it wasn't present at all.

NTFS specifically has file forks ("Alternate Data Streams") and I guess you could use those to store a type, although whether using forks would be a good idea or not is up for debate.

[shawnz]

This seems like the same kind of argument as saying that because JSON doesn't support the number formats I like, it would be better to use a notation that doesn't support types at all. Well, I think the reality has shown that in fact having some support for types sometimes is the more pragmatic way of doing things.

If those types aren't enough for your use case, then you will be forced to roll your own types in some binary/string data anyway, so it seems like it's strictly more work if you just always force everyone to roll their own.

And even then you still end up with the possibility of people using the wrong syntax for your hand-rolled types, like not quoting values that are supposed to be strings or quoting values that are supposed to be numbers.

Besides, wouldn't it be easier to fix this just by adding some more types, or deprecating everything except REG_SZ or something? What's the advantage of moving to a directory based model?

[TeMPOraL]

Don't see how this problem would be included in files. For every setting in the registry, there's a piece of software (and ultimately, a group of people behind it) that claims ownership to it, and determines the correct type for it.

File-based configs on Linux have the same problem anyway. The semantics of any config file you find are defined by the application that's consuming it. Any two config files that superficially seem to be using the same format, may in fact use a completely different one - and you'll never know, up until you edit one and it blows up in your face, because it cannot parse empty lines or #-comments, or escape characters, or negative values, or values larger than 2^16, or...

Whether altering Windows registry or a Linux config file, you cannot make a correct modification without knowing what the owners of the modified settings expect.

[rwmj]

For Linux guests we use Augeas which offers a consistent interface to all the /etc files: https://github.com/hercules-team/augeas

[TeMPOraL]

The description makes it look like it's a way of presenting Linux configs as something resembling Windows registry :).