The registry has one important redeeming quality when compared with keeping settings on the file system: it’s extremely fast. The OS keeps the registry in ram, where key requests are returned almost instantly. Compare that with the number of disk seeks required to retrieve a value from a config file in /etc (hint: it’s a minimum of four, and we haven’t even started to read the file yet).
Of course, this matters much less now than it did in 1995. Most applications load their settings once at start up, and even among those that check while running very few require this level of performance tuning. There’s really very little need for an application to keep any data in the registry any more.
Even so, I think the speed improvement would be enough to make up for the deficiencies… if, that is, the regestry were organized in a sane manner. I’m sure it’s organized in a way that makes perfect sense from the point of view of the kernel, some senior developer at microsoft, or something like that. However, since we’re using a database that’s almost always in ram that won’t matter nearly as much as being organized in an intuitive manner for the user (or if you accept the idea that users shouldn’t ever edit the registry, than for developers and technicians). And this is the area where the registry fails miserably. I have four places in the registry I use on occasion (LM-Software-MS-Windows-CurrentVersion-Run/RunOnce/Runservices,
CU-Software-MS-Windows-CurrentVersion-Run/RunOnce/Runservices,
LM-Software-MS-WindowsNT-CurrentVersion-WinLogon, and
LM-Software- (useful for removing old software crud if an application didnt’ uninstall correctly).
). Beyond this I’m completely lost and I’ve spent as much time poking around the registry as anybody.
I agree with this article and all of you. The registry is a great place to put information about installations of all importances. And even though it is not secure and has the potential to break your computer, we need this stuff or you’re not going to go anywhere.
the registry was a bad idea because it is a single point of failure
However there are three types of settings
User settings - i.e. how I want the program to work/look for me
Default Settings - how a new user sees the program
System settings - how the program is confgured to work if the system runs it
These need to be stored in three different places!
So an SQL server needs only system settings and should have a configuration program that manipulates them (dosn’t matter where/how it is stored as long as it’s fast)
A user program needs some default settings (read-only to most users) and username specific settings which should not be in a central registry or ini file in the program folder or system folder (they should have no access to this (something Vista finally got right)
and ini (or whatever) in the users folder is ideal …
JM wrote “You have a server, you have multiple users with personal settings and/or state to maintain - why should they “hit the same file”? Shouldn’t any sane application provide each user with their own settings file in the their own home directory?”
HKCU (per-user settings) is stored (per default anyway) as %userprofile%\ntuser.dat.
I.e. not hitting the same file as the system registry or other users.
As for storing separate settings files… What exactly is the big difference between %userprofile%\settings\vendor\app and HKCU\Software\vendor\app? (except one is one or more files in a proprietary format, while the other is a collection of values using mostly standardized data types for storage)
Guys… .ini files is not the solution. XML configuration files tend to be glorified .ini files. What are you guys trying to solve?
Application settings should not be stored with OS settings! You should be able to back an application up merely by copying the appropriate “Program Files” directory.
There is no reason an INI file or an XML file couldn’t also be cached in memory. There’s no reason an OS API couldn’t do this automatically for an Application. For instance, when an application loads an INI file the first time through an OS API, the OS could pull the data into its own internal DB and return data from that. It could watch the original INI file even when the application isn’t running and then suck any changes into that internal DB. Viola! You’ve got a system with all the advantages of a single settings DB with all the advantages of letting the user edit simple text files.
You’ve summed up most of the reasons I hate the registry. I wanted to mention one more, though.
The Registry Editor (regedit). It’s slow, has very limited functionality, and a confusing interface.
Of course, the whole “hive” concept is confusing anyway. But how about a search that doesn’t revisit a node in one hive if it’s visited it already in a previous hive? For that matter, how about a search that gives you a list of all the matching keys/values, instead of doing them one at a time?
How about a way to indicate what values are “correct” in the data? I’m thinking, for example, about regular expressions to constrain text entry, or specifying valid ranges for integer values.
How about recording which application created or modified a key, so that we don’t have to rely on applications undoing all their modifications. Because many applications are awful at it, especially if you install as one user but uninstall as another.
sburnap: “You should be able to back an application up merely by copying the appropriate “Program Files” directory.”
Absolutely, but less and less apps actually want that, because they store the license key under HKLM\Software\Vendor\App which tends to be local to one computer (or worse: some hidden location either on disk or in the registry - or scattered around!). The app folder could otherwise reside on some network drive somewhere.
And apps using COM (as previously discussed) have less choices. (where would COM registrations go, if not to some centralized system-maintained repository?)
Surprisingly many apps work just fine if you simply copy their files – the biggest problem is usually with apps using DLLs placed in the %systemroot%\system32 folder.
I remember the first time I installed IE on a Mac. I believe it was IE 5.1 and I was on a G4 running OS X.0. I downloaded it, decompressed the folder and BAM, there were instructions simply telling me to copy the IE folder into the applications folder and it would be ready to run. I stared at the monitor for a while, flabbergasted at the ease of installation. I drug the folder over, created a shortcut, and it all worked perfectly. Oh what sweet irony, the Microsoft developed product is more easily installed in the Apple developed OS. Of course I knew even back then, it was because OS X lacks a registry.
I’m pretty sure even the old Windows 3.1 (the one running on top of DOS) had something reminiscent of the registry. Back then it was only used for registering OLE servers though.
Just checked it, and while a basic, fresh installation of Win 3.1 only has a file type registration editor I’m still pretty sure there was something more advanced. I think it appeared after installing programs supporting OLE 2.0 or whatever, I’m pretty sure MS Publisher 2.0 is such a program but my old diskettes with it no longer work
Hell, the .NET libraries for manipulating the registry aren’t even in the System namespace. They’re hidden away in the Microsoft namespace, where only desperate people and VB programmers go.
Great point. I should have singled out .NET here as an excellent Windows role model. .NET barely touches the registry, ever, which is the way it should be. Even the GAC, the most registry-like thing in .NET, is filesystem based in the c:\windows\assembly folder.
You should start regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\System.Object and the look around
Not exactly “NET barely touches the registry” and all the System stuff is in the GAC. The same happens witch any assembly that is installed in the GAC and is COM callable.
I never thought there was anything particularly wrong with the registry despite having hosed a Windows installation by bad editing. Once I saw how OS X does it, though, I realized that the Windows way of doing it is horrible. You cannot easily extract a section (say, for an application) and move it to another machine without knowing exactly where to look, and it’s different for every application and may not even be a single location. Contrast that to OS X where it is (almost always) a single plist file that you can move to another machine and you’ve effectively transferred all your settings for that application. Want to restore settings for all your applications? Just copy over the whole folder. Much more sane IMHO.
Don’t forget Mark Russinovich’s regmon registry monitoring application. (Functionality more recently also rolled into his procmon (ProcessMonitor) application.) Fire up your application and see what it reads/writes.
Personally I can see a lot of benefits of having all the software settings in a single database. Per say the registry system is a good way of doing it. At least the basic idea of it.
To be honest, the fact that applications fail when you move them is not the fault of the registry but the application. The developer of the application should have accounted for that and built in a function to update the paths in the registry when the application starts from a new location.
And all applications should have a re-built registry entries function. This means you will have to ask the user to input some information after a resinstall of windows, but it beats reinstalling the application. And to be honest, the average windows user (I hate that statement, but you can’t get away from it) does not reinstall windows (as the mater of fact, he/she probably doesn’t know it can be done )
My biggest problem with the registry is that it’s not really that scalable. It wasn’t built for applications of the size and volume we have today. And the number of applications have increased a lot too. So we have a lot of more entries in the registry then it was designed for, thus making it sluggish. Slowing down the computer at an alarming rate. Specially when you install a lot of small applications
There was a comment up there about saving the settings after an uninstall of an application. I see this as one of the main reasons why the registry is so slow. Cos all the applications leave a lot of registry entries when they are uninstalled. If you are going to use it or not.
