On 6/18/07, Bill Stouder-Studenmund <wrstuden@netbsd.org> wrote:

> How exactly did we get from XML to the Windows Registry?
>
> When you put it the way you did above, you very much sound like a Luddite.
> There are many things that Windows does, like boot off of a disk or have
> windows and command lines, that we do as well. Given the approach you take
> in this note, should we really stop doing that as well?
>
> I don't think so, and I doubt that's what you meant. As such, please think
> about specifics of what you like and don't like. I think we will be
> better-able to address issues that way.

Indeed; one should at least know what one is comparing to.  I suspect
there are more parallels with the Windows Registry here than people
think, so I'm going to describe some of it.  If this is considered
off-topic, just let me know (in private is fine) and I'll shut up.
Also note that I'm describing NT, so if you've experienced 9x, I'm
sorry and I hope you manage to scrub it from your memory.

The Registry is a hierarchical value storage system, organized by
"keys", which are basically directories.  Each key can contain other
keys, and named values.  Key paths are described much like filesystem
paths, with Windows using \ instead of / as the separator.  All
strings (key and value names, string-typed values) are considered
Unicode.

Each named value has a type associated with it.  Supported types
include string, array of strings, 32bit value, 64bit value, and binary
blob.

Physical storage consists of "hives", which are compressed databases
(1 db file, 1 WAL) that are mounted at various points in the Registry
hierarchy.  Each user account has a hive of its own, and the OS
maintains a handful of hives organized by what part of the system
needs them (e.g. security account data is in its own hive, since it's
obviously needed long before network configuration data is).

There are various other specific features, but those are the important
bits.  As a thought exercise, one might consider: what would Berkeley
DB look like as an OS-managed standard configuration service?

> I dislike the Windows Registry. My personal displeasure with the Registry
> is two-fold. 1) There was no access control for parts (AFAICT). As such,
> one program could screw it up for the whole box. I doubt we'll ever do
> this.

Each key has a standard NT security descriptor, which besides owner
and group can contain a Discretionary ACL to manage 10 fine-grained
permissions, as well as another ACL to generate audit logs for the
same.  The standard NT ACL inheritence mechanism applies.

Hive files are subject to NTFS ACLs, which keeps users from editing
other users' hives while they're not logged in.  Any active hive is
locked for exclusive access.

> 2) it used hideously long identifiers for things and uses them as keys to
> index entries. I'm not sure if they were uuids or something as large. But
> it was vile to look at the "drivers"  area and see twenty-character hex
> strings. It's one thing to use long strings (say UUIDs), it's another to
> have to understand/recognize them to understand a config file. I hope we
> don't end up needing to do this. I also doubt we will.

Whenever Microsoft needs an identifier for something, they tend to
generate a UUID.  As a practical example, network adapters are
assigned UUIDs for configuration reference purposes.  This lets the
user (re)name one at will, and keeps configuration data associated
with it no matter what order the device is detected in.

UUIDs are of course not the only solution, but that might help explain
why Microsoft went that route.

> Sure, it's not something we can't do other ways. It's more a matter of how
> much easier it makes for us to write code and build tools.

The Windows Registry is a pretty decent technical solution to the same
problem.  It's mostly the way different applications use it that
people tend to have problems with, which is a social "best practices"
thing.  Kind of like stumbling through arbitrary XML with no DTD.  If
you can deal with such issues early on, you're in good shape.