programming and human factors
by Jeff Atwood
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.
But after living with the Windows Registry for more than a decade, I'm starting to wonder if we were better off with those .INI files.
I understand the need to store truly system-wide settings in one place. Let the operating system store settings however it deems fit. The real problem with the registry is that it was exposed to the outside world. Instead of being a secure, central hive for only the most essential and global settings, over time the registry has slowly become a trash heap of miscellaneous junk settings for every rinky-dink application on the planet.
Woe to the poor computer user who naively attempts to manipulate the filesystem without first supplicating to the Registry Gods. Manipulating the filesystem is utterly obvious, completely intuitive, and unfortunately also the fastest way to break an application in Windows. You have to reconcile almost everything you do in the filesystem with that opaque, unforgiving binary blob of data known as the Windows Registry.
For instance, when I upgrade and reinstall Windows, most of the games I have installed on my secondary drive are instantly broken because they store cd-key and (redundant) path information in the registry. The game vendors' support teams will tell you to reinstall all your games and patches. Personally, I'd rather search forums and spelunk through the registry to manually recreate the two or three registry keys the game is looking for.
My life would be a heck of a lot easier if per-application settings were stored in a place I could easily see them, manipulate them, and back them up. Like, say... in INI files.
There is an alternative, though. If Windows applications weren't so busy mindlessly piling all their settings on the registry garbage dump with everyone else, they could elect to follow the new, much saner Windows Vista conventions for storing application-specific data:
/Users/Jeff/AppData/Local /Users/Jeff/AppData/LocalLow /Users/Jeff/AppData/Roaming
Local and LocalLow are for bits of application data that are truly machine-specific. Roaming is for non-machine specific settings that will follow the user. That's where the lion's share of the application settings will be. It's all explained in the Roaming User Data Deployment Guide (Word doc). However, these are still user-specific settings, obviously, as they're under the /Users folder. I can't find any new Windows filesystem convention for system level, non-user-specific settings. I suppose that's still Ye Olde Registry by default.
It is possible to write Windows applications that don't use the registry in any way. These are some of my favorite applications. But they're also the most rare and precious of all applications in the Windows software ecosystem.
Over time, it's fair to say that I've grown to hate the Windows Registry. How do I hate it? Let me count the ways:
What's depressing about all of this is how prescient the UNIX conventions are in retrospect. How many billions of man-hours could we have saved by now if some early Windows NT 3.0 or 3.5 developers had decided to turn off public access to the registry, and transparently redirected the public registry API calls so they followed simpler, UNIX-like filesystem storage conventions instead?
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.
Masklinn on August 29, 2007 2:02 AMWas 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?
Andy on August 29, 2007 2:07 AMThe 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.
AndyB on August 29, 2007 2:09 AMI 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...
Martin Hinshelwood on August 29, 2007 2:10 AMyou're only just starting to wonder?!
Harry M on August 29, 2007 2:24 AMyou're only just starting to wonder?!
Harry M on August 29, 2007 2:24 AMThe 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.
Holli on August 29, 2007 2:31 AMThe registry just plain sucks.
Windows is filled with hundreds of examples where junior programmers reinvented a wheel already rolling in *n*x, 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.
Ole Eichhorn on August 29, 2007 2:31 AMThe 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.
Shawn Oster on August 29, 2007 2:34 AMYou're STARTING to wonder if the registry was a good idea?
Daniel Talsky on August 29, 2007 2:34 AMSeveral people brought up plist. Man, that's a format that is totally braindead.
keykey/key
valuevalue/value
keykey/key
valuevalue/value
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.
Sean on August 29, 2007 2:37 AMTo 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.
Chris L on August 29, 2007 2:42 AMIs there anything that can be done about it or do we need to complain harder first is what I'm wondering?
Sander on August 29, 2007 2:42 AMWouldn't the problems all go away, if people don't store paths inside the registry?
beza1e1 on August 29, 2007 2:55 AMinstall Linux mate! or if you wanna candies go for Mac Os/X :-PPPP
Fabio on August 29, 2007 3:22 AMI 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.
M on August 29, 2007 3:26 AM@ 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? ;)
@ 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).
Rob Janssen on August 29, 2007 3:28 AM"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
Matt on August 29, 2007 3:28 AMPersonally I think the windows registry is the weakest and most outdated aspect of the entire system.
But personal opinions aside, the registry should not be trusted with any autoloading of applciations ever.
I'm not a developer, but why are 3rd party apps even in there? I use mostly open source applications to do everything I can.
All I do is go download the zip, make the folder in program files, extract, make a shortcut to the desktop and run the main programs exe.
no installer, no registry, no garbage.
Does it have something to do with multiple users?
I mean to me, an application needs to do two things in the registry:
1) establish any file associations.
2) setup its checksum for authorization if its payware.
Aside from this, what the hell is any application doing in there?
And if they must be in there, WHY IS IT NOT ALL IN ONE FOLDER?
This is seriously pathetic that systems can be crippled so badly by malware/spyware from the abuse of the registry system and also the fact that no one reads any prompt windows.
The kernel should only load apps that appear in a SINGLE .ini file or SINGLE wherever if you want it more secure.
That's it. One place, or else it doesn't open.
msconfig is not enough.
It just irks me how well other operating systems can handle simple things like this, when windows can't.
Windows does many other things so well but this one vital piece is left out.
Its a double edged sword.
my.02
Mike on August 29, 2007 3:36 AMI don't get it. What's wrong with storing application data in the app's installation folder? More specifically... why are applications denied write access to their own installation folder?
KG on August 29, 2007 3:55 AMI would like to second Andy (above) and say the new font is almost unreadable (in either Firefox or IE.) Can we please maybe have the old one back? I had to increase the font size just to read your post.
Nathan on August 29, 2007 3:56 AMI was forced to search through the registry with Regedit a couple of times. It's appalingly slow. Later, I had to do the same in Wine. I couldn't believe how fast it was. Out of pure curiosity, I checked how Wine stores its (emulated) registry.
...
Can you guess?
...
In a bunch of .ini files!
I couldn't help it - I just had to post my comment from earlier this month....
-------------------------
http://www.codinghorror.com/blog/archives/000929.html
I think we can kill a lot of birds with one stone here....
Am I the only one who doesn't understand the need of 'installing' the vast majority of applications? I can understand why we need to install system components. Things like DirectX, .Net Framework, etc...but why do I need to 'INSTALL' games or applications?
If I have a game, I want *EVERYTHING* I need to run that game in the folder I tell it to. The registry is a huge mess....screw it. Everyone, *stop* using the registry. I'd rather see a 'config.xml' or a 'config.ini' than have to spend hours digging around the registry for whatever the application added.
The vast majority of .DLLs and crap that will get copied to the system directory will never be used by anything other than that one game or application and SHOULDN'T be put into the system folders.
When you execute a file, by default, it should ONLY have read/write permission to the folder it is in, and any sub folders.
If I'm running IE and browse to some shaddy site, IE itself, should only be able to access the folder it sits in, and sub folders. That means, ALL of the data related to IE can be found in the folder and it's sub folders.
If I install another copy of a Windows OS - I shouldn't have to 'reinstall' any of my games or apps. I should be able to browse to the folder it lives in, run it, it should work. See, during the install process a bunch of crap is put into little hidden spots of the registry and files are copied all over you HD. Without those files, the game won't run....so you have to reinstall all of your games. It's crap.
What I'd like to see is a filesystem based security system that views individual executable files as 'users'. Each app, each game, each EVERYTHING, you can run has individual permissions that you can look at and modify. By default, it can't do anything but read and write to it's folder and subfolders. If you want IE to be able to put files in C:\MyFiles - then you need to set the permissions of C:\MyFiles to allow IE access to write to it. Anytime an application attempts and fails to read or write data that doesn't belong to it - you'd see an error message. You know what file did it, and what it was trying to get at.
Taking it one step further, using this model, the VAST majority of applications could/would run just fine as long as the appropriate updates were made. The few installs that really should be 'installed' in the current sense are mostly well-known MS or other big name company products. If I go ot install the .Net Framework that *should* be a real install, but MS could certainly give it a 'stamp' of approval; just like it does with signed drivers.
If someone gets a 'HappyBunny.exe' and they run it, it won't be able to do much of ANYTHING. It has read/write access to some temp folder under IE. Even if it exploits some sort of buffer overflow, or something along those lines, and can excute code, the IE process, only has read/write access to it's folder. If the application requests access to other folders, the user would get the error message with a 'allow/deny' type choice and then, if they allow, since HappyBunny.exe isn't digitally signed by MS - they get a big BIG ugly warning saying that there is virtually NO REASON for an application to need more access.
Administrator accounts could grant the programs access to system folders. Regular accounts couldn't. This would *only* affect the installs of software that has a legit reason for accessing system files (virtually none). Everything else could be installed from the regular accounts.
RobDude on August 14, 2007 04:29 PM
RobDude on August 29, 2007 3:59 AMThe registry fails us because it breaks the cardinal rule about localizing changes to known places.
However, program settings are not the problem. It's the registration of the COM servers that prevents most apps from being able to be run off a USB key. I'm not sure if there's a simple answer to that one though.
Chui on August 29, 2007 4:14 AM
On an offtopic note, did something change in your font rendering? im using Firefox and its quite hard to read.
I love the Windows Registry!... Just kidding. I guess it does its job, despite not being an optimal solution.
I've actually once managed to break .exe file association using regedit... fixing that was real fun.
I personally like XML and ini configuration files, but they should be kept in the dir with the rest of the application's files IMO. Why does everyone want to put a memento of themselves to my Windows dir?
Looks like nobody here actually administers a network. XML files in the same directory as the EXE file - real smart when c:\program files is READ ONLY to the average user. (It's for stupid programs like this that Vista introduces a virtualisation trick where programs can apparently write to such areas - they can't in reality; it gets shunted into a per-user application compatability area.)
Or how exactly administrators are supposed to roll out an individual setting - you're proposing they all learn XSLT and run an XSLT processor at logon? Heck, I'm also a dev and I have issues reading XSLT!
It's really nice knowing that an app's config is likely to be in hkcr\software\vendor\program; and that I know anything in hkcr will roam properly when the users logs onto another machine. (Which happens an AWFUL LOT in the corporate world.)
A bunch of silly files means that logon processing slows down with roaming profiles. Thats assuming the dev put the files in the correct place.
KG: Of COURSE applications are denied write access to their installation folder. If you don't deny the user write access to there; the user will screw around with it and muck everything up. (When an application is deployed by Group Policy, the MSI runtime will run with local-machine admin privs to install the package.)
Honestly, I suspect too many devs don't know the real world where supporting a hundred windows computers is considered small potatos.
S on August 29, 2007 4:31 AM"Honestly, I suspect too many devs don't know the real world where supporting a hundred windows computers is considered small potatos."
Of course I don't administer 100 computers AT MY HOME. I have VERY different needs than do medium/large-sized companies. Convenience is more important for me than dummy-proof security - I understand it's the other way around for you. So why should my OS contain all the same restrictions?
KG on August 29, 2007 4:47 AMFrom the DUH department:
Mr. Atwood has apparently run out of things to blog about.
Jim on August 29, 2007 4:57 AMYep, go with those ini files (or xml)!
Then deal with the performance hit of searching out keys or trying to update values. Don't forget to implement proper locking logic to handle multiple users hitting the same ini file.
Doesn't anyone remember why ini files were deprecated?
XML can have comments, blah blah. Sorry, there are lots of partial implementations of XML out there. You may just break your application by putting in comments.
Grow a brain and think it over.
Sheesh on August 29, 2007 5:02 AMI'm sorry, but your stance on the registry strikes me as that of a Luddite.
First of all, the registry materialized in 1993 with NT 3.1. Win95 had a scaled down version of the registry, sans security, sans decent file system, etc... That you mention Win95 at all seems to be a calculated way of making the registry look especially bad and unreliable.
Secondly, a bunch of ini files scattered around the drive is not the solution to any problem I know of. A bunch of ini files stored in the Windows directory is not the solution either.
Storing setup information hierarchically makes sense. Specially when you happen to install more than one app from some of the larger vendors. (MS Office stores stuff under HKLM\Software\Microsoft, all Adobe products presumably end up under HKLM\Software\Adobe -- all very neat -- per user storage ends up under HKCU)
Yeah... Where does your ini files go for the per-user settings? %userprofile% directory? Messy. That is the way Win 3.1 did things. That is exactly what most of us wanted to avoid.
"The registry has to be in sync with the filesystem. Delete an application without "uninstalling" it and you're left with stale registry cruft". Uhm, yeah? It has nothing to do with the filesystem. If the uninstaller doesn't clean up after the application, then it does not matter where it stores its settings. You're not going to find them any easier if they're not stored in the registry. Au contraire. (on a side note: Do you really want to lose personal settings when re-installing an application, if you ever faced having to do such a thing? MSI has reduced the need for re-installations a lot, but not completely eliminated it when faced with broken install scripts)
Finally, it is not the fault of the registry that YOU install "every rinky-dink application on the planet". Clue: Don't install every rinky-dink app. At least not when you are running as administrator. Because then you will require every rinky-dink anti-spyware, anti-virus and personal firewall application there is, which will further molest your registry.
--
Rune
That's why we have /etc
keitaro on August 29, 2007 5:27 AMGeez you make me feel old.
I remember back in the day when applications scattered ini files (and other config files) randomly about my hard drive. From applications that required their ini be in c:\windows (not d:\windows, or bob forbid, d:\apps\SomeApp) to ones that liked to have c:\SomeApp for the application, c:\SomeData for the data and c:\config for their .cnq files (hello Canon)). Oh, and the inevitable editing of system.ini and so on, which often had humorous results (if you weren't the one trying to make it work).
The registry was a distinct step up from that mess.
But it just proves the old adage: there's always a better fool.
Moz on August 29, 2007 5:31 AMI once saw a program on one of the odd high-number channels, where they interviewed this guy at Microsoft. Turns out he was on the team that originally invented the registry. They showed him giving a powerpoint demo and the first slide was something like
About the registry:
sorry, sorry, sorry, sorry, sorry, sorry, sorry, sorry!
bigjim on August 29, 2007 5:41 AMI'm sorry, I left off this gem:
"The registry is a single point of failure."
If you have a bunch of configuration files in a directory somewhere, and you delete those files... Isn't that a single point of failure?
The registry OTOH is automatically backed up. In every version of NT, it has always been possible to boot using the "Last good known" configuration.
Yes, there is a warning in most KB articles. This is because regular users (who have no business editing e.g. .ini files, let alone the registry or God forbid xml files!) sometimes stumble across these articles.
"Let's say you wanted to move an application to a different path on your machine, or even to a different machine altogether." I have done this several times. Not an issue if you know what you're doing. (You can load another registry hive temporarily, or you can connect to a remote machine's registry)
Your point about the lacking comments is valid.
--
Rune
at first i thought that windows registry is a good idea. That was before my pc is cracked by spywares.
ok.. enough of that.. The only good thing i see at the registry is the managements of defaults.. default is good, i think..
other than that it's plain crap..
Allan on August 29, 2007 5:47 AMThe biggest problem are all those broken apps that scatter their settings across the whole system but change the storage mechanism for configuration settings will not automagically any broken application. So in reality it’s not the registry that is broken -you are complaining about broken Windows application. A brain dead programmer will make any storage system a “trash heap of miscellaneous junk settings”.
“Manipulating the filesystem is utterly obvious, completely intuitive”
Only for us experts/computer gods. For the average user manipulating the file system is very difficult, the biggest problem are folders. These are neither obvious nor intuitive.
“You have to reconcile almost everything you do in the file system with that opaque, unforgiving binary blob of data known as the Windows Registry.”
Look at Unix: You have to reconcile almost everything you do in various files scattered across various folders (/etc/..., /usr/…, /var/…, /opt/…, /home/…) in various different formats. sendmail.cf vs tnsnames.ora vs smb.conf vs httpd.conf – such fun!!
“For instance, when I upgrade and reinstall Windows, most of the games I have installed on my secondary drive are instantly broken because they store cd-key…”
Plus filter drivers for their copy protection, and PunkBuster, and more. Most modern games generate unique machine ids during install and there you will never be able to simply copy them – this is by design and independent form the storage mechanism
“the new, much saner Windows Vista conventions”
These conventions are the same as the Windows NT 4.0 conventions, btw :-)
“can't find any new Windows filesystem convention for system level, non-user-specific settings”
% ALLUSERSPROFILE% ?
“single point of failure”
INI files are a “single point of failure” (at least for the application, editing system wide plain text config files can break your computer in a similar way) so you should make backup copies of those files as well. There is a German saying:
Beginne Deine Arbeit nie
Ohne Sicherheitskopie”
„Never start your work without a backup copy”
“XML config files are reasonably human-readable, and they allow as many comments as you see fit”
Only for us experts/computer gods. The average user will have no clue and it’s very easy to break an xml file – a missing / and the whole file is useless. INI files are much more robust.
“in sync with the filesystem”
This is true for any mechanism. Only settings stored in the program folder are deleted but what about start menu entries, shell extension registration (file type handlers for double clicking), etc ? You will need an uninstaller to remove these settings and a poorly written uninstaller will stay a poorly written uninstaller no matter where the settings are stored.
“The registry is monolithic … Good luck extracting the relevant settings for that one particular application”
Look at Unix: Good luck extracting the relevant settings for that one particular application from various config files scattered across the whole file system with various formats (some plain text some not)
“What's depressing about all of this is how prescient the UNIX conventions are in retrospect”
Unix is even more broken than Windows but there are less broken public Unix applications.
It’s not Windows or the Registry that are broken. The main problem are the great many broken Windows application done by brain dead programmers. And there is no technical solution for this.
Kriz on August 29, 2007 5:53 AMAs others have pointed out, .INI files have their issues to (inconsistent format, can be scattered around, multi-threaded access), but *nix has made it work relatively well. That said, I pity the fool who has to look at sendmail.cf for the first time.
But why not replace the registry with the obvious? A database. MSDE is small and light, provides central access, is way faster than any of the other technologies, has great APIs and has plenty of tools for management.
I'm always amazed that Microsoft fails to use one of its best technologies (SQL engine) for other products (registry, desktop search index, Exchange information store, ...)
David Avraamides on August 29, 2007 5:57 AMI just want to make clear that regardless of my earlier comment, I'd like to drop the registry for many things as well, if anyone could come up with a half-decent way to overlay required settings on config files in a centrally-administrable manner. (In such a way that the apps know, so settings can't just be changed back every time the app is opened.) I know for a fact that this is one of the issues holding back Firefox adoption in some businesses, having heard from other admins. But the open source community doesn't see this as a need at all, and perhaps actively loathes central management. I've been hoping Novell or Red Hat would come through for a while, but not yet.
I like the idea of "only have write access to your own folder", which vista's and terminal server's redirection partially gives you, except that it's the user's home folder
Really, the number of developers who think that the one true home for ini files is the program folder rather shocks me. I guess that happens when you've never touched a machine that someone else uses. Mozilla does an excellent job with registry, centralized, roaming, and local data; more developers could take a few tips from them instead of outright rejecting alternatives. (Aside from the fugly Mork files.) All it needs is a way to lock down without a custom plugin and it would be perfect.
Foxyshadis on August 29, 2007 6:07 AMMy vote is for getting rid of the Registry.
David Ginger on August 29, 2007 6:14 AMFunny also that no one is mentioning the use of .Net app config files (whatever.exe.config) which are simply XML files with application settings in them, but in a standard format.
Does that mean no one is really doing .Not^H^Het development?
David Avraamides on August 29, 2007 6:16 AMAs an aside, XnView is one software that gives you complete choice - you can set it to save to the registry, an ini in the program folder, or in the user's application data. A little bit of stuff always gets written to all three, but only a couple of small, unimportant files.
Portability and debugging are enormously easier when the software actually gives you the choice.
Foxyshadis on August 29, 2007 6:36 AMI hate the registry as much as the next guy but one positive that comes out of it is the ability for one application to check to see if another application is installed (what version etc..) Also as annoying as it may be the registry in many cases is a huge anti-piracy tool.
Ryan Smallegan on August 29, 2007 6:38 AMSheesh said:
Don't forget to implement proper locking logic to handle multiple users hitting the same ini file.
Under what usage scenario do you have multiple users changing the same setting at the same time (and thereby requiring locking)? And if it does, what the hell is wrong with standard file system locking?
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?
Or do you really suggest that your preference for a bright yellow desktop should override mine (and all other users) preference for the standard sky blue?
Seriously, is there _any_ situation where conflicting updates to settings file is a problem? Do you really have multiple administrators performing uncoordinated configuration changes on a single box at the same time?
Grow a brain and think it over.
I've already got one thanks.
JM on August 29, 2007 6:42 AMRyan, good point but that would also be possible if the registry was used for nothing more by applications than to write the location to their "ini" file.
As for those saying ini files are bad because they are scattered around... I'm not sure what your complaint is. Do you believe my jedi knight 2 key mappings really need to be saved in the same spot as my microsoft word settings?
Jacob on August 29, 2007 6:51 AMUsing the registry means that you're updating global machine state to install your application. Sometimes this is exactly what you need, but more often it is nothing like what you need. Accessing global state has all kinds of unpleasant implications on user ability to have multiple versions of your app/library installed, it is a substantial downside that needs to be balanced by a corresponding upside to be worthwhile. Such upsides are very rare in practice.
I've written libraries that get used by dozens of in-house projects at once (analytics for banks), and the first key idea of such libraries is xcopy-type install, otherwise you are absolutely and completely hosed - how else can you have several versions running on a single machine, used by applications developed by competely independent teams? While the registry is a reasonable match in some cases, it is hopelessly overused in the Windows world.
A sensible default posture is to request uses of the registry to be positively justified, rather than taking it as a starting assumption.
Matt Morris on August 29, 2007 7:04 AMI remember many many years ago, back in the days of Windows 3.1/3.11, Microsoft told developers to contain all of their application files in one directory. This was at a time when application INI files were starting to clutter the win.ini and the system.ini. The Microsoft fix was to have the application INI files located with the application and not in the OS INIs. Seems to me that would have worked
Dudley Overbey on August 29, 2007 7:10 AMHow appropriate. I post about the aggravating nature of the registry last night, today I get to "fix" a DVD-R drive that mysteriously fails to load with error code 39, by making this cryptic registry change:
http://forums.techguy.org/hardware/572840-dvd-burner-stopped-working-drivers.html
(see post #4 -- remove "LowerFilters" from the "{4D36E965-E325-11CE-BFC1-08002BE10318}" key under HKLM\System\CurrentControlSet\Control\Class)
Works like a champ now. :P
Jeff Atwood on August 29, 2007 7:10 AMI don't think I have ever agreed with anything you have ever posted more than this.
DOWN WITH THE REGISTRY!
I personally try to only use INI files and XML config files. Every once in awhile I must admit that I sin and store stuff for my applications in the registry.
Billkamm on August 29, 2007 7:14 AMYour article reminded me of this quote;-
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
nuff said.
Mark on August 29, 2007 7:37 AMI think alot of the posters are missing the point: the registry is a tool like any other. It has both benefits and drawbacks.
Pros:
* Database-like architecture means reads and particularly writes are fast
* Standard API
* Easy to share among various instances of a running program, run by the same user (yes it does happen sometimes, get used to it)
* Theoretically harder to muck up at a low level than text-based files
* Everything is in the one place
Cons:
* Everything is in the one place
* It is hard to split out the settings for an application. In comparison a gamer-level user can manage to extract file-based settings
* Low level implementation not as fast or robust as it could be
* Cannot use "xcopy" deployment
* COM was built on top: COM is an even bigger problem
* centralised packaging not common in windows: packaging is an even bigger problem
* Contents are not self documenting
* Contents are not externally documented (Try to *accurately* enumerate *all* the com ports in a windows system sheesh!)
-Andrew
Andrew on August 29, 2007 7:37 AMActually the problem is that MS has never written any useful tools for the registry. The null problem wouldn't be a problem if we had a decent registry editor and useful command line utilities (possibly Powershell??) I won't list the other commands that are missing, I leave those to your imagination.
But I can't close this message without mentioning the almost complete lack of documentation, and what I think are implementation problems, mostly a lack of date stamping for entries but also the way the same information is stored in multiple places, and the decision to show, what is it, three generations of some registery information (current control set, and all it's little brothers) in the program they call an editor.
It may not be all it should be, but if MS would get of its collective backside and provide the tools it could be very much better than it is.
Dan on August 29, 2007 7:38 AMEver tried to make a single entry in an ini-file readonly for the user?
I wish you lots of fun...
Only with the registry you could administer hundreds of machines in an easy and consistent way.
Only with the registry there is a way to double-click a .reg-file and enter its content automatic into the registry.
and on an on and on.
Registry is like a database, ini-files are like chaos.
Jeff: "How appropriate. I post about the aggravating nature of the registry last night, today I get to "fix" a DVD-R drive that mysteriously fails to load with error code 39, by making this cryptic registry change:"
This is a problem with the device driver. Maybe part of the problem is that since everything is stored in the registry, people blame the registry for everything.
-Andrew
Andrew on August 29, 2007 7:41 AM
Thats awesome, Windows is becoming more like Unix with every release and I'm all for it. I do wish they'd adopt the same plist configuration format found in OSX, its XML based, very flexible and easy to work with.
Ini is kinda primitive when compared to plist, and Unix's convention of having no convention here is a poor idea.
All in all a good move by Microsoft.
Mark on August 29, 2007 7:43 AMSaying the registry is "obsolete" is ridiculous. The article and some of the comments seem to imply the registry concept was OK in it's time, but is now outdated. Rubbish. It was never OK. The registry never did ANYTHING but break software and occasionally kill your windows installation.
What are the advantages of a single place to store system settings? Is there a single one?
Michael on August 29, 2007 8:00 AMDon't you think that .NET's move to .config files proves your point without even making it? 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.
I think Microsoft wants the registry to go away as badly as you do. But as Michael Sinz once said, "Programming is like sex, one mistake and you have to support it for the rest of your life."
Nick on August 29, 2007 8:02 AMThe registry COULD have been a good idea.. err... nvm.
What the registry should've been was a database tracking localized .ini files, which could be binary or plain-text files containing the same information. That way if you just delete the folder containing the application, the OS can't find the file and assumes it's gone, or asks to search for it.
The only thing missing from linux is a microsoft's media center. Until I can figure out how to hook my xbox360 and my laptop/pc together so I can watch TV, use that neat sports thing, and download showtime movies.. I don't know if I can justify the switch. Gentoo is by far my favorite OS.
Sean L on August 29, 2007 8:10 AMThe 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.
Bill on August 29, 2007 8:20 AMthe 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 ...
Have to agree with Jeff on this. Classic example of filling a need in the wrong way, and millions suffer.
@Jaster
User settings are stored in NTUSER.DAT and UsrClass.dat in your user profile.
Machine and default settings are stored in %systemroot%\system32\config (in serveral files) - read only for standard users/LUAs
System settings are stored in %systemroot%\system32\config\systemprofile in NTUSER.DAT and UsrClass.dat - read only for standard users/LUAs
systemprofile and UsrClass.dat have been added with Windows 2000 the rest is unchanged since at least Windows NT 4.0
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?
"the registry is bad, m'kay?"
Rune on August 29, 2007 8:52 AMApplication 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.
sburnap on August 29, 2007 8:53 AMYou've summed up most of the reasons I hate the registry. I wanted to mention one more, though.
1. 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.
A. Lloyd Flanagan on August 29, 2007 9:03 AMsburnap: "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.
Rune on August 29, 2007 9:03 AMI 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.
Mattkins on August 29, 2007 9:06 AMI'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 :(
Niels Hansen on August 29, 2007 9:07 AMHell, 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.
Jeff Atwood on August 29, 2007 9:33 AM@Jeff
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.
Kriz on August 29, 2007 9:54 AMThe registry also still isn't the ONE place where you can find things like application settings, even for modern programs.
I reflected upon this the other day on my blog...
http://dansdata.blogsome.com/2007/08/18/they-seek-config-here-they-seek-config-there/
...and some commenters chimed in with some interesting extra info.
Daniel Rutter on August 29, 2007 9:58 AMWhen I write freeware apps I always use YAML. It's like XML but without the angle bracket tax.
I've always liked the idea that if you want to delete an app, you delete the directory hierarchy and that gets everything.
Simple.
engtech @ IDT on August 29, 2007 10:00 AMI 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.
Brian Donovan on August 29, 2007 10:01 AMAs a mac user and programmer. I do not envy you microsoft guys.
Sam McDonald on August 29, 2007 10:02 AMYou're preaching to the choir, Jeff
Kevin Fairchild on August 29, 2007 10:03 AMDon'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.
a href="http://en.wikipedia.org/wiki/Mark_Russinovich"http://en.wikipedia.org/wiki/Mark_Russinovich/a
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.
Thomas Winsnes on August 29, 2007 10:17 AMRune
JM's remark about each user getting their own file was a response to the claim that using INI files had locking issues, he wasn't talking about the registry in that case.
a on August 29, 2007 10:20 AMDude, I've been a fan of your blog for the past year, but ever since you started advertising, your posts have been really really boring. I'm sorry but I'm getting ready to hit the unsubscribe button.
Brian Reed on August 29, 2007 10:23 AMThis remind me of a talk channel9 did with Rob Short, who I believe in this interview covers why he created the registry, and his thoughts on the topic.
http://channel9.msdn.com/ShowPost.aspx?PostID=148820
Indeed, the registry does suck. Game developers probably store the CD-Key and area code for the nearest burger king (oops dev error!) because normal users who want to look cool by opening up cd-key.ini and changing it just end up screwing things up anyway. I guess it's a saftey thing ( or not because a link to the registry is in the start menu :/ )?
Danny on August 29, 2007 10:41 AMPeter Wilson is absolutely correct. The other reasons may be secondary benefits, but the real purpose of the registry is control. We're computer geeks, so we evaluate things by their coolness; most people are about social domination and being top dog. (Look at the Pew Center studies on happiness and income for one aspect of this.)
Geno Z Heinlein on August 29, 2007 10:44 AMA bunch of text/xml files is better than this registry things, yes. Either way, only power users are going to touch these things, and power users will be happier with easy to maniuplate and move around text files.
The issue then is to have those text files in a simple, logical location. For this to work, you need very straightforward simple APIs. And I do agree that Mac OS X got it right on both counts: the pref system is very logical and flexible. And the APIs are so simple, e.g. in ObjC:
[[NSUserDefaults sharedDefaults] setValue:someObject forKey:@"SomeSettingKey"];
mypref = [[NSUserDefaults sharedDefaults] valueForKey:@"SomeSettingKey"];
where someObject can be a string, a hash, an array, a number, or any object that has an serialize method defined.
charles on August 29, 2007 10:49 AMI have 1 word for you:
Linux
http://www.youtube.com/watch?v=EwL0G9wK8j4mode=relatedsearch=
Gandazgul on August 29, 2007 10:49 AMI don't have a problem with the OS itself using the registry, but I would prefer per user application settings to be saved as a configuration files in my home directory. This makes them easier to backup, and easier to delete when I decide to restart from scratch.
Jeff Flowers on August 29, 2007 10:55 AMI haven't used Visual Studio for a while, or MFC, but the apps that were generated created a registry entry for each different project. Since I was working through several books, I created over a hundred projects. Sure enough, that meant over 100 registry entries.
And every demo program you download creates dozens of entries.
"binary blob of data"
That's what I call redundancy.
Rottz on August 29, 2007 11:06 AM"binary blob of data"
That's what I call redundancy.
Thts wht I cll rdndncy
David Dawkins on August 29, 2007 11:14 AMYou're *BEGINNING* to wonder??
I wrote one small app that used the registry. I learned my lesson, I haven't touched the registry since unless I need to inform Windows about something.
As for the comments about locking and .ini files, there are cases where it's needed. An .ini on your own machine isn't going to be an issue but a network app that maintains a configuration on a server could realistically be hit by multiple people and thus needs protection.
Loren Pechtel on August 29, 2007 11:29 AMI'm pretty terrified to see all the comments here advocating storing settings in the same folder as the application (in Program Files). I'm guessing you guys are the ones that write apps that need Administrator privileges to run because you think apps have write permissions to their install directory. And your apps don't work on multi-user machines, either.
The user's AppData folder is the only good place to put app settings.
Ben Hollis on August 29, 2007 11:40 AMRegarding the article: AMEN BROTHER.
A quick note for those of us who, like me, wondered what "LocalLow" was about? I dug down (ha ha) into it and found this:
http://msdn2.microsoft.com/en-us/library/bb625960.aspx
The executive summary is: LocalLow is where applications running at a "low integrity level", that is, not fully trusted, can store local settings. These processes do not have write access to "Local". (Although, from what I understand, they have read access.)
tcliu on August 29, 2007 11:40 AMWith all the negatives around, here are some positives:
- The registry has a hidden backup which the OS keeps in Sync with the main one. If the main gets corrupted, the backup kicks in. It's also easier for backup software to backup the regsitry for you. Even programs like 'Spybot - Search Destroy" do it for you.
- Fire regmon.exe and look at all the calls going on. If we had ini files scattered all over the drives and the system continously reads them, it will slow down the system.
- I never had a problem with editing the registry. Export the key you're going to edit and do your edits. If you screw up, import the export file. Simple and easy.
- Control using permissions. It's not easy to change permissions like on the file system
- A single place to search for a key or value whose location you don't know.
- There are tools out there that can delete orphan entries.
- Registry offers control for casual users. You don't want them editing ini/xml files just because they are text files.
I think a hybrid system is best. Let the OS use the registry for itself and the applications can use their own settings which are placed in the app's folder.
Abdu on August 29, 2007 11:43 AMThis was another example of Microsoft taking an idea from someone else and implementing it in the worst possible fashion.
NeXTstep (and OS X now) had the defaults command to read/write preferences, but each app has it's own file, so if one program screws up, it only screws up it's own preferences.
And the culture on OS X is that if you don't find any preferences, you write new default preferences, unlike windows where most apps, if they don't see any preferences, throw up their hands and just exit.
jpb on August 29, 2007 11:53 AMI think the registry wouldn't be a horrible mess like it is now if the write access to it programmatically was more limited. Ie. let apps only write to some specific area for app data storage.
In theory storing things in a single registry-like place is a good idea. The Singleton/Storage/Registry/whatever design pattern, anyone?
Someone mentioned the fact that the registry is backed up. That is actually a very good point in favor of using it. Hadn't thought about that.
I happened to be at the 1st Windows NT developer conference back around 1990. During a Q/A session after a presentation on the registry (introduced with NT, not Windows 95) I stood up and asked whether the system would contain any useful _metadata_. I had been mentally comparing it to Apple's system of resource forks and decided at the time that it was a disaster in the making. The answer as no. I can't remember exactly what else I said but it was something to the effect that "this will be a disaster without decent and consistent and auditable metadata."
If you don't know what metadata is, please disqualify yourself from replying to me or commenting on the registry design feature; it will save us all a lot of time.
Paul R. Potts on August 29, 2007 12:14 PMWell Duh, the registry sucks.
*Abuse* of the registry sucks. And perhaps the original design was flawed, in that public access was allowed to the innards of the registry from day one.
The point of this post isn't *entirely* to pile on the many faults of the Windows Registry. Discussion of alternatives is useful; even in UNIX, you need a place to put centralized settings. You could even defend the registry as a useful construct for certain tasks.
We're trapped in an abusive relationship with the Windows Registry. The question we should be asking ourselves is "as software developers, how can we change or fix this"?
Jeff Atwood on August 29, 2007 12:23 PMKG @ 3:47pm hit the nail on the head.
Always remember that Windows and Office are designed primarily for enterprise customers. If something in Windows makes life a bit easier for corporate network admins but hell for home users, Microsoft will choose to screw the home users every time.
Note that Microsoft products that don't have the baggage of serving the enterprise market (Xbox) are actually quite good.
Nathan Bowers on August 29, 2007 12:35 PMImho, 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.
Tony on August 29, 2007 12:42 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |