Fog Creek Software
Discussion Board

The MSwin registry

I think Joel is too harsh on the unix way of life.

NT draws on unixisms just like anyone else these days, minus some, plus some. (Now what was that about software evolution superiour to revolutions?) One thing NT/win32 has added is the system-wide registry.

While touted as a feature by Joel (and Microsoft) it is terrible in Real Life. I will try to summarize what I dislike most about it:

1. A common format will always be a a least common denominator. The registry is a name=value hierarchy. That's not very good for a number of things (for example think a routing table). It's possible all right but not suitable. That's why lots of software will store some things in the registry and some things in separate files (so you'll have data files anyway).

2. The registry is binary and proprietary. You can't manipulate it with your standard tools (IDE, editor, grep, make etc.), only with a certain program (which in its standard incarncation is a *pain* to use).

3. The largest drawbacks lies in the culture. The registry is a system-wide storage and not per program. It is hard (or impossible) to treat it as such. What would be the equivalent of 'chmod -R a-w ~/.xemacs'?

In Real Life, all programs store their preferences spread out all over the registry, and there is no practical way of extracting all preferences belonging to a certain application.

4. There is no standard for storing system-wide settings as opposed to per-user. It is impossible to store system defaults in a standard way. (This could be done a lot better than the unix way of /etc, but is completely lost in NT/win32.)

5. Now, the real reason why we have the system registry is a more abstract cultural concept. It is to have a storage that belongs to "the machine" instead of "the user". It is not, and is deliberately designed not to be, the same thing to "move an application" to another computer as to just "move the corresponding files".

You are supposed to run the installation process, at least one time *for each computer*. You have to click-through the license agreement! This is to imprint the users mind that one installation -- one computer -- one license.

(Obviously, this doesn't scale. You can't just run applications from a shared filesystem. This has spawned peculiar solutions to install software on many computers, most which looks like macro-style programs that run installation programs.) Some applications take this so far they are designed to only run from the system drive.

These are my basic thoughts against the registry concept. I bet there are many more out there. Now I don't mean the unix dot-files are the final answer either, but the situation in Real Life is much better in that world. You have the access control, one user can easily copy another users settings when they need, if you share your home directory you will automatically share the settings, they are easy to manipulate using standard tools (say if you as an administrator needs to do bulk changes for some users).

Jonas Bofjall
Thursday, December 12, 2002

I don't think the point was that (in this instance) Windows with its registry was *better* than Unix.  The point was that Unix developers can't be smug about the simplicity of Unix -- because it isn't.  The registry solves *some* problems of system configuration, whereas system configuration in the Unix world is much more ad hoc.  There's a *lot* to know about how each application gets its configuration information in Unix; it is somewhat easier in Windows.

Both development 'worlds' require lots of hard-won knowledge; one group can't point to the other and say: look what a complex platform!  I'm glad I don't have to deal with anything messy like that!

Thursday, December 12, 2002

I came across a Windows program once which had a menu item which created a .reg file containing the program's current configuration, which I thought was a neat feature. It's a pity there isn't a standard API for that. I always meant to write a Delphi component to do it but never got around to it. I could be wrong but I think the program was the excellent CSS editor TopStyle from

It's interesting that Microsoft themselves now seem to be moving towards XML config files for .NET.

John Topley
Thursday, December 12, 2002

Unix is harder. Plain and simple.

A couple of weeks ago, I needed to read a config file from a program written in C. Any type of config file, don't mind, I just needed to keep some parameters changeable. Nothing complicated. So I figured that I just needed to find some library that provided this functionality.

Simple, right?

At the end, I just wrote my own lib. And now we have Yet Another Config Format under the sun.

Leonardo Herrera
Thursday, December 12, 2002

You should note that despite the existence of the Windows registry, plenty of configuration information in Windows (for plenty of applications) are stored *outside* the registry.  So Windows *can* still have the "Yet-Another-Config-File" syndrome.

Thursday, December 12, 2002

Interesting few paragraphs here:

Thursday, December 12, 2002

Strangely, he implies that MSN doesn't run on Windows NT because of the registry but doesn't explicitly say it.

John Topley
Thursday, December 12, 2002

From the article mentioned above:

An NT system starts off its fastest the day it is installed and slows down the more it is used. Adding Visual Basic 6.0 professional to my NT system (a process which expanded the registry by 5 megabytes) caused my 266 MHZ K6-II to start performing about like a 386-20.

To me, it does not seem logical that the registry size can affect the overall performance of the system. Any comments from NT gurus?

Thursday, December 12, 2002

From the article:

"In NT on the other hand, not only is the registry soon the largest file in the operating system, it is also the one which is changed the most often."

- He's obviously not heard of the page file.

John Topley
Thursday, December 12, 2002

( I refer to NT and its descendants, I only use 2K  or later)

1.  The Registry can store several different data types, including binary data. ACLs are stored as binary.  Course arbitrary binary data is hard to manipulate with third party tools, but you can do it.  You can even store large strings or even icons, in the registry ( though that is dumb ).  The registry, like all of winnt its ucs2.

2.  The Registry is plainly exposed through an API.  Several tools exist that can covert a tree to text and then import it back into the registry.  The registry is used alot. Its used by several processes concurrently, its needs to be fast and thread safe. Config files dont cut it.  The Reg to Text to Reg tools arent used much outside of development, but they are still freely available.  One super reg tool that was ruined in win2000 was regini, which because of problems with localizing its output, no longer outputs anything, grr.

3. Historically MS has had suggested evolving guidelines.
Program Specific - HKLM\Software\Company\Product
User Specifc - HKCU\Software\Company\Product.
COM Specific - COM HKCR\....
Many if not most big name software programs adhere these guidelines. Ours does.

4. ( also See 3).

5. With a roaming profile you can take the HKCU part of your registry with you.  Installing a program is rarely as simple as copying files on windows and thats not just because registry's not a flat file.  Its of course possible to write software that is easy to move and uses the registry.
Probably the biggest obstacle to moving is COM registration.  regsvr32 is supposed to solve some of this but it doesnt.

The OSData article makes conclusions about win2k but only shows data for NT4. 

_Actual Registry Issues_

Insufficient Docs of Settings.

Limit on core system registry. Hit the limit, too bad for you. Possible fixed in XP or later, I dunno.

Registry Backup Mgmt is a pain.

Registry Cleanup is a pain.

No quota on the Registry.

Anonymous Windows User
Thursday, December 12, 2002

Hmm... there's a lot of misunderstanding about how the registry is structured in this thread. Like the fact that HKEY_CURRENT_USER switches when the user logs in, but HKEY_CURRENT_MACHINE is always the same, therefore allowing easy per-user and per-machine settings.

It's really just a different culture. Windows people want an API - it's unfortunate that it took too long for "best practices" for the registry to evolve, but modern apps do tend to use the registry responsibly. I know that if I want to find the settings for Norton Thingamabob, I should look in HKCU\Software\Symantec\Norton Thingamabob for per user settings.

Unix config files have their own problems: where the heck are they? There's no standard at ALL for where config files are. What format are they in? It doesn't matter that they're all text if I have to write a different flippin' parser for each one. The WORST config files are the ones that are actually program code (.emacs, I'm pointing at you!) - it's next to impossible to programatically query and manipulate them.

Like I said, it's a cultural thing. Unix devs like the freedom to do their own thing. Windows devs like not having to worry about writing config parsers or figuring out where to put the data.

Chris Tavares
Thursday, December 12, 2002

Anonymous User wrote:
"The Registry can store several different data types, including binary data. "

Hey, I didn't say it was *impossible*. Only clumsy, you have to resort to application-specific formats that you can't edit.

"The Registry is plainly exposed through an API. "
Just like I said. But the standard client program is  really bad. With a human readable format, you can edit using your favorite editor, grep, make, perl, whatever utilities you already know how to handle.

"Historically MS has had suggested evolving guidelines."
Problem is, if they exist they are unclear, not exposed through the API design, and nobody follows them. It's a very practical problem, a real life system administration problem, and not a theoretical one.

"With a roaming profile you can take the HKCU part of your registry with you."
And that solves .. absolutely nothing!

"Probably the biggest obstacle to moving is COM registration."
Which could be designed in a multitude of easy-to-administer ways. Just look at MacOS for example. Or the System V /etc/rc*.

I agree on your points as well. ('Management' and 'cleanup' are good examples of what problems I was trying to describe above.)

Jonas Bofjall
Thursday, December 12, 2002

You can defragment registry hives using PageDefrag from SysInternals (    I've found that doing a PageDefrag and a disk defrag tend to make a sluggish system run a little snappier.

Friday, December 13, 2002

*  Recent Topics

*  Fog Creek Home