Was The Windows Registry a Good Idea?

One of the hot new features introduced with Windows 95 was the Windows Registry. The Windows Registry offered a centralized database-like location to store application and system settings. No more plain text .INI files splattered all over your system. Instead, issue a few easy API calls and your application settings are safely nestled away deep inside the registry hive.

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/08/was-the-windows-registry-a-good-idea.html

they could elect to follow the new, much saner Windows Vista conventions for storing application-specific data:

Er Jeff is it me or there’s absolutely nothing new about that?

I mean on my 2K and Windows boxes i already have a %APPDATA% envvar leading to %HOME%\Application Data (which admittedly sucks since it has a space in it, on the other hand by default user accounts are in %SYSTEMDRIVE\Documents and Settings so it’s a minor issue) and quite a few software (most notably any Mozilla soft, the latest Winamp versions if you check “1 profile per user” and a few others) already store their userconf data there.

Some (adobe for example, I think) store stuff in both %APPDATA% and the registry, but that’s a slightly different issue.

Anyway storing application-specific per-user settings and data in files is already very easy to do and standardized (if you know what you’re doing) since 2K.

Was The Windows Registry a Good Idea? No

Was it better than the implementation of INI files? Yes

Solution : A better implementation of ini files

The two things it solved was speed and centralisation
Ini files are slow, but don’t need to be?
Ini files are scattered but don’t need to be

If I run a program I would expect it to save my settings in my space not in it’s program folder, not in the system folder, not hidden somewhere (seemingly randomly) in the registry, if it’s a global setting - isn’t that what All Users is for?

Aren’t there Windows API calls that can manipulate .INI files in the same way one can manipulate registry keys?

The same arguments about the registry could be applied to any Application or System that uses a database as a back-end.

You know, like Oracle, MySQL and SQL Server. Somehow, businesses trust storing all their critical data (payroll, AP, Billing, sales, etc.) in a “single point of failure”.

Yet they manage to stay in business.

Granted, the registry might not have been as robust, but that is an implementation problem not a design issue.

I think the real problem is that in the same way that a poorly written application can mangle data in a DB, each application/installer that uses the registry is responsible to manage it’s own data.

For example, EBay would be a mess if everyone could add data to their database directly - instead you go through tightly controlled web and rest/ws interfaces.

On the other hand, by not putting in strict interfaces, the registry lets developers add data in almost any format and structure. Hence, it can appear to be a mess to an end-user.

I feel your pain, I have spent many a dark day trawling through the regestery for the holly grail that is a working application…and usualy find is a Shrubbery and someone shouting Ni! Ni!

As you can see, sanity is actualy a hinderence for registery manipulation…

you’re only just starting to wonder?!

you’re only just starting to wonder?!

The registry is a terrible thing. I never used it for programms I wrote. I like to store all my application configuration in a xml file. That even allows me to make changes with a texteditor while I am at a customers pc.

The registry just plain sucks.

Windows is filled with hundreds of examples where junior programmers reinvented a wheel already rolling in nx, and did it wrong. They may be smart, but they are not experienced, and they ignore the outside world. Over time this problem has become worse, and Windows has become dumber and less compatible.

The registry is like communism, a great idea in theory, a horrible idea in practice.

One of the worst things that the registry begot was the COM registration system. The quagmire of GUID keys and convoluted registration schemes could only have thrived in the dank unseen place known as the registry. Of course they realized too late that it was horrible and their half-hearted attempt to fix it with side-by-side COM registration (read registry-free COM registration for true xcopy deploys) was almost as full of issues as the problem it was trying to solve.

I’ve stayed as far away from the registry as possible for the last few years and it’s amazing how many installation and application issues go away once you do. These days I use anything from INI, XML, YAML and even JSON to store settings and they are all much more usable than the registry ever was.

I hear a lot of what Foxyshadis above is saying but I disagree with the issues of settings file speed and com servers moving being “easily fixed” by just re-registering. As someone that disliked the registry early on I used a custom file format that was probably closest to what YAML is today and it came pretty close to being as quick as the registry. Secondly I’ve also done enough COM development to have the scars and in any deployment besides the most trivial simply re-registering COM servers is rarely simple. If you’re lucky the worst will be that the uninstaller gets confused and leaves a few dozen stray keys, at the other end I’ve seen entire suites of applications from different vendors brought to their knees because someone from IT moved an application from one share to another and did a blanket regsvr32 in the new folder.

I will agree with him though on the fact nothing can rescue bad application design. Whether a bad app abuses the registry or the filesystem it’s still being abusive. Poor developers expect their tools to make their work look skillful while good developers use their skill to pick the right tools. In this case the registry is rarely the right tool.

You’re STARTING to wonder if the registry was a good idea?

Several people brought up plist. Man, that’s a format that is totally braindead.


Talk about a total bastardization of xml. Shows a complete lack of understanding from the format creators. Plus it’s a bitch to parse because you have to keep track of the previous sibling.

To Andy: The APIs are ReadPrivateProfileString and WritePrivateProfileString. Their documentation comes with a warning not to use them. I’ve read that they are not thread-safe amongst other problems.

Is there anything that can be done about it or do we need to complain harder first is what I’m wondering?

Wouldn’t the problems all go away, if people don’t store paths inside the registry?

install Linux mate! or if you wanna candies go for Mac Os/X :-PPPP

I think the reason that /etc is not as hellish to work with is that it uses the same namespace management and plaintext manipulation skills and conventions the many people are familiar with for other applications. If the registry had better tools and conventions then it could work just as well.

@ beza1e1 : I think the problem is that once the paths have gone poof from the registry they generally don’t assume any kind of “sane default”.

You’d not only have to make that practice go away but all the books recommending it, too. Time for a bonfire? :wink:

@ Sander: complaining won’t work since this is one of those nice things that regular customers solve with a format/reinstall or more correctly, “call the kid from next door to clean up my Windows”. Besides, stepping away from it will again result in backwards compatibility, unless you have some nice catching mechanism for installers that grabs every value written to the registry and emulates it back again when an application asks for it.

.Net apps seem to be going the right way with their .config files. (unless these are for something else and I’m misinformed).

“I used to sit beside the guy who invented the registry at microsoft. It was designed as a temporary measure to deal with the .ini file system mess.” - Raymond Drewry

1 Like