8 ms·

Why the Windows Registry sucks … technically

123 points by fogus 17y ago

larsberg 17y ago
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 17y ago
  The registry existed in Windows 3.1 for COM. It was from that it was expanded to hold every possible setting.
jpablo 17y ago
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 17y ago
  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 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 17y ago
    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 17y ago
      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.
- stinky613 17y ago
  Yeah--Why does it matter that the registry is endian-specific? Doesn't Windows only run on little-endian processors (x86, x86-64) or am I mistaken? Is there any reason why a new version of Windows couldn't do away with the registry and create a layer of abstraction to allow programs in a "compatibility mode" to run normally but have its registry interactions translated to the new system? Wouldn't that be a similar principle to what Wine does?
  - rleisti 17y ago
    It would mean that if you port windows to a large endian machine, then you can't share registry files (ie. as in roaming profiles). It's not as much about the file format as it is about the implementation (simply dumping C structures to disk). I think what the author is saying is that it's just a crappy implementation.
    - jpablo 17y ago
      I don't think there's any way at all to share the whole registry file even in the same endian machine. It wouldn't fly anyway since it's very machine specific. The way you'll share parts of the registry will be using .reg files, those are just plain text so could easily be read anywhere.
- xpaulbettsx 17y ago
  Not to mention - the registry hive file is an internal data file for Windows; why would the author have the expectation that it would always have the same format.
- gvb 17y ago
  The windows-specific issues are probably a large part of the problems that happen when you try upgrading Windows versions, e.g. XP to Vista, Vista to Win7, and no end in sight. Based on what the article points out, I would speculate that Microsoft spends a lot of energy trying to catch and fix all the ways the registry migration breaks when doing an OS upgrade. Not only is that is all wasted energy, it will never hit 100% success rate because there will always be something the porting engineers never saw in their systems.
SamAtt 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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?
      - xpaulbettsx 17y ago
        Because Registry / gconf et. al. provide cheap notifications of when a specific key changes. This is the reason that a registry-type solution is useful, as well as helps performance. Your solution means that every app interested in a setting has to put a file change notification on the conf file, then reparse the entire thing and diff it to see what changed.
rabidgnat 17y ago
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 17y ago
  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 17y ago
    > You could create a library to read the setting, and everyone could just use the library. You've just described the registry conceptually.
- glymor 17y ago
  The article was arguing that the Windows registry implementation is bad. He thankfully avoided the usual unix vs windows philosophizing. Basically it's a boring debate as Linux does have a number of X windows related registries. For example GConf and X resources (xrdb).
Zak 17y ago
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 17y ago
  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.
- JoachimSchipper 17y ago
  Some would argue that X is an ad-hoc, informally-specified, bug ridden, slow implementation of half a window system. The specifications are pretty clear, even if some are honoured more in the breach than in the observance, but otherwise they'd be right. ("This is not a bug; this is a design decision.")
csomar 17y ago
isn't the database itself a file?
- mfukar 17y ago
  With dozens of mechanisms, interfaces, data structures built on top of it, yes. A database provides advantages a file does not.

123 points by fogus 17y ago

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 17y ago
The registry existed in Windows 3.1 for COM. It was from that it was expanded to hold every possible setting.

jpablo 17y ago

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 17y ago
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 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 17y ago
  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 17y ago
    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.
stinky613 17y ago
Yeah--Why does it matter that the registry is endian-specific? Doesn't Windows only run on little-endian processors (x86, x86-64) or am I mistaken? Is there any reason why a new version of Windows couldn't do away with the registry and create a layer of abstraction to allow programs in a "compatibility mode" to run normally but have its registry interactions translated to the new system? Wouldn't that be a similar principle to what Wine does?
- rleisti 17y ago
  It would mean that if you port windows to a large endian machine, then you can't share registry files (ie. as in roaming profiles). It's not as much about the file format as it is about the implementation (simply dumping C structures to disk). I think what the author is saying is that it's just a crappy implementation.
  - jpablo 17y ago
    I don't think there's any way at all to share the whole registry file even in the same endian machine. It wouldn't fly anyway since it's very machine specific. The way you'll share parts of the registry will be using .reg files, those are just plain text so could easily be read anywhere.
xpaulbettsx 17y ago
Not to mention - the registry hive file is an internal data file for Windows; why would the author have the expectation that it would always have the same format.
gvb 17y ago
The windows-specific issues are probably a large part of the problems that happen when you try upgrading Windows versions, e.g. XP to Vista, Vista to Win7, and no end in sight. Based on what the article points out, I would speculate that Microsoft spends a lot of energy trying to catch and fix all the ways the registry migration breaks when doing an OS upgrade. Not only is that is all wasted energy, it will never hit 100% success rate because there will always be something the porting engineers never saw in their systems.

SamAtt 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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?
    - xpaulbettsx 17y ago
      Because Registry / gconf et. al. provide cheap notifications of when a specific key changes. This is the reason that a registry-type solution is useful, as well as helps performance. Your solution means that every app interested in a setting has to put a file change notification on the conf file, then reparse the entire thing and diff it to see what changed.

rabidgnat 17y ago

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 17y ago
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 17y ago
  > You could create a library to read the setting, and everyone could just use the library. You've just described the registry conceptually.
glymor 17y ago
The article was arguing that the Windows registry implementation is bad. He thankfully avoided the usual unix vs windows philosophizing. Basically it's a boring debate as Linux does have a number of X windows related registries. For example GConf and X resources (xrdb).

Zak 17y ago

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 17y ago
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.
JoachimSchipper 17y ago
Some would argue that X is an ad-hoc, informally-specified, bug ridden, slow implementation of half a window system. The specifications are pretty clear, even if some are honoured more in the breach than in the observance, but otherwise they'd be right. ("This is not a bug; this is a design decision.")

csomar 17y ago

isn't the database itself a file?

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