
Why the Windows Registry sucks … technically - fogus
http://rwmj.wordpress.com/2010/02/18/why-the-windows-registry-sucks-technically/
======
rabidgnat
The registry's implementation is bad, sure. However, a global key/value store
is extremely useful. I changed the default background color in Windows from
'White' to 'Light Gray,' and it works for almost every application I use.
Visual Studio, Explorer, even some webpages! For years, I turned the
brightness of my monitor down, but that severely hinders readability of some
color schemes.

How would global shared settings look without a registry? Like Unix
configuration files. This is a step backwards, as there is no unified way to
read Unix configurations. Some things are stored in environment variables,
some things are stored in XML files, some things are represented as special
files, and some things are stored in INI-style files. Something like window
color would be handled by the display manager, but other configuration
settings would need to be hunted down at runtime.

What's really better, "read system.window.background.default_color.[rgb] as
ints," or "parse /etc/x/conf/x.conf as an .ini file, look for the variable
background_color. It is stored in the format (r,g,b). If it is not present,
the default is (255,255,255)."?

~~~
rleisti
You could create a library to read the setting, and everyone could just use
the library.

I like the Unix way better myself, as it's more about building up
functionality through composition, rather than setting out to create grand
unified architecture. Speaking (possibly too) generally, I find large
architectures tend to be harder to fix.

~~~
FooBarWidget
> You could create a library to read the setting, and everyone could just use
> the library.

You've just described the registry conceptually.

------
SamAtt
Good article but I think everyone at Microsoft knows the registry was a
mistake at this point. It was designed in 1991 after all.

Microsoft does seem to be slowly moving away from it (see point #9). But
outright replacing it just isn't an option.

Do a cost/benefit analysis and you realize that it would be very expensive to
replace it (while maintaining backwards compatibility) and 99.9% of people
don't care one way or the other.

~~~
old-gregg
That didn't stop Gnome from re-inventing it with gconf :-( Ughh...

Now rgrep /etc for a config setting is broken, apps leave garbage sitting in
there upon uninstall and you need a stupid GUI tool to deal with it.

~~~
jpablo
What's bad about giving programmers a standard API to store config settings so
they are in a central place and can be tweaked by administrators and users
using gui tools (for other people you can still grep ~\\.gconf or use they
command line tools).

I don't think the Windows Registry is a bad idea by itself, it's just a poor
implementation and very badly organized.

~~~
old-gregg
Nothing's wrong with it. Make it a simple text file and place it in /etc where
it's supposed to be anyway. Don't make users chase different config locations
for different programs.

UNIX _already_ has a standard for storing configuration. It is simple, text-
based, scriptable and standardized.

And there is no need for "standard API" here. Its too late. GConf doesn't
cover 99% of whats on a typical Ubuntu system, so why did they invent this
"standard" for 1% of all system settings? Why fragment the system?

~~~
kelnos
"UNIX already has a standard for storing configuration. It is simple, text-
based, scriptable and standardized."

False. Go ahead and cat a few files in /etc/:

nsswitch.conf: key/value, separated by colon. Lists of values are space-
separated

fstab: per-line record-based, 6 space-separated fields

passwd: per-line record-based, 7 colon-separated fields

fuse.conf: key/value, separated by equals sign

hdparm.conf: hierarchical, using curly braces; inside that, key/value,
separated by equals sign

What "standard" are you referring to?

~~~
FooBarWidget
People who think /etc is a standard don't know what they're talking about.
Almost _every_ app has its own config file format; some of them just
superficially look like each other but really aren't. I can give more
examples:

\- Apache: hierarchical key/value, separated by space. Hierarchy can be
started and ended with XML-like-but-not-quite syntax, where the hierarchy
container itself can contain a value.

\- Nginx: hierarchical key/value, separated by space. Hierarchies can be
started and ended with brackets.

\- screenrc: key and one or multiple values, separated by space.

\- nanorc: key/value, separated by space.

\- /etc/network/*: shell scripts.

\- inittab: ??? no idea what the formal syntax is.

People who complain about GConf with the reason that "/etc is superior"
usually have no clue how things really work, yet they still behave like
they're experts.

~~~
rbanffy
And why on Earth would someone think he has the One True Way of storing
configuration in a file?

I see nothing wrong in each program storing configuration data in the most
convenient way for them.

For Gnome applications there could be standard APIs. And, as a bonus, they
should store the configuration data in plain text files according to whatever
format Gnome finds convenient, but not making us use specific tools to edit
it, much like the Founding Fathers of Unix didn't tie config files to ed.

Which is how GConf will look in 10 years.

~~~
imd
GConf files aren't binary; they're XML. It may not be the greatest format, but
it's editable and rgrep-able, and gconf-editor documents many of the keys.
Sometimes it's good to declare One True way of doing things just so you know
what to expect, and if GConf really doesn't work for your app, you don't have
to use it; there are still plenty of GNOME config files outside .gconf/.

~~~
rbanffy
I have played with Gnome config files a couple times and never quite
appreciated their organization. With all due respect (I never contributed a
single line of code to Gnome) I think that keeping config in lots of human-
friendly formats such as yaml is a better solution than grouping stuff in XML
files.

It's not nearly as bad a solution than the Windows Registry, but it's not
perfect either and has some good chances it's not a step in the right
direction.

------
jpablo
I agree that the registry is a mess and probably badly implemented as well.

But a few of the criticism coming from the linked blog seems of the form "the
Windows Registry is only compatible with Windows".

Since the Registry is very specific to the current version of Windows the user
is running I don't see why, from a technical point of view, should effort be
wasted in trying to make it more compatible with other platforms or versions
of Windows.

The registry is an abstraction and there's only a few supported ways to access
it (regedit, .reg files and the registry API basically).

~~~
fragmede
The linked blog has created an new way to access the registry that happens to
also run on Linux. The larger project (<http://libguestfs.org>) aims to be
able to make changes to virtual disks that comprise virtual machines without
having to actually turn them which is pretty neat if the same registry tweak
needs to be applied across a bunch of machines. But that explains why their
new registry access api needs to be compatible with the various windows OSes.

~~~
jpablo
Yeah, I saw that. My point is that the registry wasn't designed for that.

I'll be the same as complaining that the format of the /etc files is not well
document, is not standard across different flavors of UNIX and everyone sticks
whatever they want there.

~~~
rleisti
It isn't really the same. Anyone that needs access to something in /etc can
get what they're looking for without having the first pierce a difficult
binary format. Deciphering what they get back is another issue, but typically
it's just a text file, so you can generally figure out how to parse it if you
need to.

------
larsberg
It helps to realize when and why it was created. The internal lore, as best I
recall it is below...

At the time, application developers stored settings in INI files in the
\Windows directory. Reading this name=value file was very slow. The registry
was an attempt to centralize storage of that data, speed up application
startup by reducing the time required to settings data from it, and to respond
robustly to disk corruption.

Of course, after it was created, everybody and their grandpappy (COM,
MSI/Darwin, etc.) decided to abuse it as a general-purpose store. Now that XML
file load is considered zippy enough to be done at application start,
developers are encouraged to have a private configuration file in their own
application directory and per-user ones in the per-user directories.

~~~
wvenable
The registry existed in Windows 3.1 for COM. It was from that it was expanded
to hold every possible setting.

------
Zak
It sounds like the Windows registry is an ad hoc, informally-specified, bug-
ridden, slow implementation of half of a filesystem. (Amazing how Greenspun's
Tenth Rule can be slightly adapted and apply to so many different situations)

If you should find yourself creating an ad hoc, informally-specified, bug-
ridden, slow implementation of half of X, _stop_! Throw it away and use X
instead. You'll save yourself and everyone who has to interact with your
system a whole lot of grief.

~~~
somejan
And since a filesystem is an ad hoc, informally-specified (or unspecified, how
long did it take before linux could read ntfs?), slow (for some things: no
indexes), bug-ridden (FAT 8.3 name limit, limited metadata such as file
types), implementation of a database...

But filesystems have been in use long enough that most bugs have been fixed or
worked around in the tools. And of course the guys who invented the
'filesystem' didn't have any databases to use instead.

------
csomar
isn't the database itself a file?

~~~
mfukar
With dozens of mechanisms, interfaces, data structures built on top of it,
yes. A database provides advantages a file does not.

