Imho, the registry is still good for “plugging” programs into the OS (contextual menus, default programs, etc) and for enumerating the hardware. What really should reside in xml/ini files, in user settings folder or program folder, are the HKCU/SOFTWARE/vendor and HKLM/SOFTWARE/vendor keys.
there’s nothing wrong with the registry. A registry is better than having 10000000000000000 small files.
Jeff, I’ll second the view that game installations intentionally break if you reinstall the OS or parts of it. Part of a brain-dead mentality of making the user keep the install disks, and better yet going out and buying a new set.
In reading all the comments, no one has had much problems with INI files. Wow. I can remember fielding calls from clients who directly edited the files (encouraged by support), and then wondering why the changes didn’t work. Then you have to figure out if they deleted a line, put invalid characters in it, or as was often the case had multiple copies of the INI scattered around the file system. I was happy REGEDIT was so hard to use in cases like these.
It’s faster for an install to look for specific keys in the registry than the whole filesystem (and possibly network mounts) for previous versions.
Your points are valid, but INIs and XML files have their own faults.
I agree. The registry is obsolete and should be completely replaced.
Well Duh, the registry sucks.
I love Mac OS X’s system of plist domains [User, Computer, and the little-used Network] along with MAC-address-tied ByHost plists in each for truly machine-specific settings (Power and Networking, mainly).
Applications can be run from anywhere, but generally can’t write to /Library (using ~/Library instead) unless they’re in the Applications folder.
Couldn’t agree more! In fact, all applications I write use INI-files and not the registry. This is in part because I don’t want to clutter my own (or other peoples) registry with application-specific “junk”, but also because this way I can copy my application to another computer and still keep all my settings. Couldn’t be easier!
Still, I remember back in the good ol’ days when I spent time “cleaning” my sys.ini and win.ini files. They weren’t all that pretty either 
The question we should be asking ourselves is “as software developers, how can we change or fix this”?
Change it? Not until after I retire 
That easily corruptible registry is job security for some of us.
Of course, I’m kidding.
Since the registry API can be re-mapped to anything (e.g. a pile of discrete hives instead of one big clusterfsck), another possibility is to remap an access to HKLM/…/$APP_NAME into one that modifies /Program Files/$APP_NAME/Configuration/app_hive.dat. Admittedly this is a huge simplification (keying off $APP_NAME would require a fair bit of trickery to get right), but I think unbundling the registry would be the single biggest improvement you could make.
Chalk me up as another one who agrees with you on this. As a matter of fact one of my first podcasts I did this was part of the subject (1:50). My point was that the mistake made was letting everyone and their brother have access to from what I understand was originally suppose to be the private playground of Windows alone.
http://www.winextra.com/2007/08/16/off-the-cuff-dont-always-blame-microsoft/
Not a single positive? Like the registry being hundreds of times faster? (This is mainly an issue with MFC apps that like to write out their full settings every time you change one; this leads to painful performance drops in apps like MPC with .ini writing on.) Or enabling hierarchical storage without custom parsing? (XML config files fulfill this need now, but they’re tortuously slow for some applications. Not as big a deal as back in the NT 3 days.) And how do you implement organizational policy across random files in random formats, without a standard API, short of enforcing every single setting? Heck, I even use group policy for home use, as it’s simpler and more resistant to reversion than direct editing.
Would you really expect more than a few badly-behaved apps to really be that much better with ini files? You can throw your settings anywhere on the system just as quickly as you can put them anywhere in the registry, and I’ve seen it done many times. Many applications totally mess up the local/roaming, and want to put settings in hidden folders right in your home file, if they even bother with anything but machine settings. Installers are total junk, strewing important files all over, and up until the MSI switch most were still 16-bit! (MSI is worse, since you can be boned trying to remove something by not having the original media available, regardless of registry locations.) Macs have the right idea, with their monolithic folders, but many third-party apps still put per-user settings right in the shared program folder.
The second most common problem with moving files - com servers - can be easily fixed by just reregistering everything in the folder after moving. (for %A in (.dll;.exe) do regsvr32 /s %A) You need to modify it a bit on 64-bit OSes though.
I’ll grant binary and opaque, although there are ways to read it in *nix now. All performant databases are that way, though.
I would have liked to see the registry split into more files than the big 5 keys, such as one file per subkey of HK*/SOFTWARE, and of course the win9x registries could’ve been more bulletproof, but that’s the only major issue I have with it.
I have to disagree with this article wholeheartedly. The general registry idea was a good idea, just not as it was designed. Here’s how I would have designed it in retrospect:
-
Create logical packages of registry items. Every app creates its own logical area, which is orthogonal to where the keys physically exist in the tree. A package can be simply installed and uninstalled with a single API call, as well as automatically in Windows Installer.
-
Give keys an expiration date and force developers to think about how long they should last. This gives Windows the ability to more intelligently flush things out. Plus, it makes a lot of registry-based dev cases easier (such as timestamp keys).
“I can’t find any new Windows filesystem convention for system level, non-user-specific settings.”
C:\ProgramData\Vendor\Application
(or CSIDL_COMMON_APPDATA)
“they could elect to follow the new, much saner Windows Vista conventions for storing application-specific data”
Weren’t they Windows XP conventions already?
“10 years… and I’m starting to wonder…” LOL!
Made my day, thanks!
I’m not so sure I agree.
As many people have stated here the registry is just a tool which can be abused, but then again any configuration store could be abused. The abuse comes from the fact that many applications change settings that other applications are dependant on, but I would have to say that in many cases that is not something we can get away from.
If we wanted the settings to be one specific value forever then it would be hard coded and not in a config file. The whole idea of config files is that values can change depending on need. So this kind of makes this whole rant a bit obsolete.
The main issue with the registry is that it makes your applications non-portable. As an old Mac user, I miss the days when you could have an app on an external hard drive, take it to a different machine, and run it there.
And the sad thing is, there’s nothing gained by using the registry that makes up for this crippling loss of functionality. In fact, the registry will accumulate, over time, numerous errors that lead to the need to reformat windows every other year or so (or just resign yourself to the errors).
I totally agree!
The main purpose of the Windows registry wasn’t to store application settings in general, it was to store OS settings and application information which can be shared whith the OS and potentially with other applications. This was supposed to be something helpful in order to allow the OS to be aware of the installed applications.
-
The original goal makes sense: It allows to increase OS usability (centralized OS settings, uninstall points, known file extensions, etc.).
-
However these usability improvements have been accompained with real big drawbacks: Portability of applications, difficulty solving installing/uninstalling/updating problems, reduced OS transparency, and the idea that we have some kind of ‘tumour’ within our machine which grows without control. However the registry cannot be blamed of all the vulnerability issues just because Windows home users work usually in root mode, this is a cultural problem.
-
My point is that all these problems are not derived from the original idea of a ‘registry’, but from its implementation and use.
Three letters, XML.
The Windows Registry was not introduced with Windows 95, it was introduced as part of Windows 3.1 and NT, though most applications (and most of Windows) at the time still used INI files to store configuration data. There were exceptions, which I recall from my early network administration days: Novell WordPerfect, for example, used the Registry previous to Windows 95.
As for whether the Registry was a “good idea,” yes, actually it was. The alternative was a proliferation of INI files, which was a horrible idea, even then. Microsoft also had concerns about the integrity of plain text files. Obviously, the Registry got complicated and convoluted, and today it’s a mess. But for the time, it made sense, just like floppy disks, CRT monitors, and other technology that seems quaint today. We should be using XML files for configuration data today, I suppose (i.e. proliferating text files). In 20 years, that too will seem silly.
–Paul
SuperSite for Windows