I would have to definately agree with you. Our company has moved off of using the registry to using the application data directories for storing settings in xml.
Interesting-- Paul Thurrott is right, the registry existed in some form as far back as Windows 3.1:
Oh yes. Letâs all move our settings to XML configuration files. I donât believe config files are a better solution. We just exchange one set of problems for a different set of problems. Now instead of having my settings strewn throughout several different hives and keys in the registry, I get to try and find my settings in a series of files which may/may not be logically named and buried in one of several directories. For example: I want to copy my setting for MS OneNote 2007 to another machine. I have OneNote settings stored in AppDate/Local/Microsoft/Office, AppData/Local/Microsoft/OneNote, AppData\Local\Apps\2.0\Data\JJ81VLRM.H8Z\CLHYBMCG.2TG\onenâŚtion_f1fe1dc54fbb5b9b_0001.0000_87e1612fa5f8a27f\Data, AppData\Local\Apps\2.0\WJ7L7QJ0.11R. And this is just in the Local directory. I havenât even looked in LocalLow or Roaming, much less in the AllUsers or Default folders. I am no more certain that I will capture all settings using the configuration file method than I was certain I would find all the settings using the registry. Oh did I mention the fact that since I am forced to elevate priveleges to install any software, I might be lucky and also have some key settings stored in my administratorâs folders. What a wonderful solution. This is SOOOO much better.
I might choose a different screenshot.
I think that there have been a number of good and bad points made. Sadly, they have been completely lost inside the myriad of âme tooâ type posts (e.g. âitâs called XMLâ, âuse Linuxâ).
I will attempt to summarize all of the points made here. Please excuse me if I miss anything out.
========================================
Positives about the registry:
-
Itâs a single place for looking for most settings, rather than having numerous config files scattered in any number of locations.
-
For applications which use the registry correctly, itâs a convenient and consistent place to store information.
-
Every key (folder) in the registry can be secured, providing fine-grained control over which items a user can see or modify.
-
You donât have to worry about file system permissions when modifying global data.
-
Having a binary storage in memory is more efficient than using lots of files on disk. For example, if you use an INI file, it gets rewritten every time you change even a single entry.
-
It is automatically backed up by Windows, so you can revert to a âlast goodâ state if needed.
-
By being an opaque store of data, accessible only via APIs, itâs harder to corrupt via manual editing. An XML file may be rendered useless by missing a single character.
-
The HKEY_CURRENT_USER hive roams with the userâs profile, making it portable.
========================================
Negatives about the registry:
-
Being an opaque binary blob, itâs a lot harder to make manual changes to should anything get corrupted.
-
Because the registry is so widely used, any corruption will affect multiple programs, not just one.
-
Because of its size, itâs possible for applications to hide data just about anywhere. This makes some settings incredibly hard to find.
-
There is no enforcement of structure. So long as a user has sufficient access rights, any program they run can write to anywhere in the registry.
-
Itâs a lot harder to extract settings for a particular application from the registry.
========================================
Issues that will occur regardless of storage mechanism:
-
There will always be cryptic or hard-to-find settings. Using Jeffâs example of the DVD burner not working, the issue was with an incorrect configuration value, not the registry itself. If the data was stored outside of the registry, it would still require some kind of configuration file change.
-
Itâs possible to stop an application from working by editing or removing configuration values.
-
Configuration files and entries can be scattered in any number of locations, making them hard to back up or remove.
-
If an application is removed, but doesnât clean up after itself properly, there will always be some usage of resource(e.g. disk space). In the case of the registry, it may also use up some memory.
========================================
In the end, itâs up to developers to code appropriately for the situation. The registry is a good place to keep settings, so long as itâs not abused. Other times, itâs a better idea to keep configuration files on disk.
No matter how you look at it, the registry is just a storage tool for settings. It can be used, and it can be abused. Sadly, itâs been far too abused, and this is the cause of all our pain.
The guy at Microsoft who accidentally created the Windows Registry agrees with you! Tony Williams. See his Code Behind interview where he is asked about it. http://www.researchchannel.org/prog/displayevent.aspx?rID=5212fID=1806
Just a note to those who want some sort of control based on the application being run⌠Sadly, itâs not that easy.
There are just too many ways to get an application to run whatever code you like:
-
Modifying the application on disk (the same way viruses do).
-
Inject a new thread into a running application. Any check of âwhich executable is running this codeâ will report that application.
-
Locating a snippet of binary code that can cause execution to temporarily enter the third-party application, then back into yours. This would allow you to pass any checks of the call stack.
Thatâs why operating systems tend to use user-level permissions rather than application-level permissions. Itâs much harder to spoof a user than an application.
Using a text only browser (damn your CAPTCHA!)
Qt, by Trolltech handles configuration files quite elegantly in a cross platform manner. It uses the native settings saving mechanism to handle any custom preferences. Thus, if Microsoft made a substantial change away from the registry, Qt based applications would not need editing!
Of course, knowing Jeff Atwood, chief architect of Microsoft cocksucking, heâll rather stick to inferior technologies.
For someone just beginning to question the registry, in a dry blog post, itâs clear that sensible advice like âUse Qtâ wonât become apparent for another ($NOW - $INCEPTION_OF_REGISTRY) years.
Sean: â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.â
It isnât a bitch to parse because you simple look for a tag and then the following item is the object. Plus itâs pretty easy to parse on OS X:
[NSDictionary dictionaryWithContentsOfFile:@âpathtofileâ];
or
[NSArray arrayWithContentsOfFile:@âpathtofileâ];
Youâve now got the whole file loaded into an array or a dictionary
Registry is not going away. If Symantec is not paying for this âfeatureâ such that it canât âpossibly be removed from windowsâ then they should. And the hackers, and the IT staffsâŚ
Nice posting, though we all know that the Registry was in fact one of the bricks in MSâs great masterplan for obfuscating all otherâs code to such an extend that they could over time easily take over all the application vendorâs revenue by supplying better solutions built on âlocal storageâ⌠
(JOKEâŚ!!)
.t
âHow do you handle DLLs? Put a copy of every DLL that your app links with in the app directory? How about the DLLs that they link to? Oh, you want to have a common place to keep system DLLs so they donât have to be in every app dir? What do you do about apps that need different version of a system DLL? (Itâs called DLL Hell).â
Essentially, the problem is that the installer has to be used as a priviledged way of putting an application on a computer. If you reformat, or move to a different computer with the same share but different installed dlls, then things break.
Iâve long thought about a way of trapping all the changes an installer makes to disk and then packaging them so that the folder could be simply copied from one computer to another. Use a sort of secret directory which contains the registry keys and files installed to external directories. When taking it to a new machine, it would essentially look through the secret directory as a sort of $PATH for registry keys, and install them if they donât exist.
And yes, you could cache dlls in that directory (hard drive space is cheap) and when running for the first time on a new computer, go through the same process an installer does, examining the computer for dlls and copying the needed ones to the new machine.
Should be a relatively straightforward hack, especially if you can easily detect when an installer is running.
How can we make this better?
We really have 3 different kinds of settings.
-
System settings
Store these in the existing registry for compatibility reasons or better yet, upgrade the registry to MSDE as suggested earlier. -
Application settings
Store these in a centrally located location with a separate file for each application to make it easier to move application settings between folders and pcâs. I donât buy the myth that this will slow down apps as the extra 200ms needed to read this file easily outways the performance hit for keeping a 500MB registry file in Ram (or a cache). Besides you can cache the file anyway. -
User settings
User settings should be stored in a folder under âMy Documentsâ and called something logical like âMy Settingsâ. This allows you to back them up, move them between machines and ideally, transfer them to a web service so you can access your settings anywhere on the planet.
Its an evolutionary process. The Registry was brought in to fix the problems caused by INI files and ended causing a whole different set of new problems. Think of how many attempts Microsoft needed to get ADO into the version they have now.
I agree with Jeff, at some point one has to stand back and take the 2,000 foot view and rethink things.
I think what we are going to see is virtualization of the registry and the equivalent of app-armor. Every app with run either in itâs own virtual space or a protective shell. At least on windows. What I really wish is that linux/unix would move all itâs config to xml. intead of me having to be some sorta voodoo shaman to know that 1 extra tab can spell doom, and what all the parameters means
The Gassy One posted on His Blog:
Read This Now!
I am 100% on-board with this one, and am currently writing registry-free applications!
BTW, that reference comes from another favorite blog.
Just an observation, but almost all of the posts talk about âmoving an applicationâ by copying the install folder somewhere else. This is fine for statically-linked stand-alone apps.
How do you handle DLLs? Put a copy of every DLL that your app links with in the app directory? How about the DLLs that they link to? Oh, you want to have a common place to keep system DLLs so they donât have to be in every app dir? What do you do about apps that need different version of a system DLL? (Itâs called DLL Hell).
How about newer apps that communicate with other apps (photoshop and a scanner control app)? How about all of those COM interfaces that let apps bind at run-time? How do I find RPC functions in a common place?
I think that if you go back and substitute a substantitive app, perhaps even a browser like FF, you either have a huge app directory filled with everything needed to implement modern componentized applications, or you have something like the registry that can be located by any app and queried for the location of common shared copies of things.
Do you really want to download 100 or 200 mb install packages that have all this stuff in them? As bad as the registry is, the world of .rc (er, .ini) files is as archaic as the isolated apps that used them.
Myself, I kinda like being able to drag-n-drop things in the GUI, mash up some COM components into a new app without rewriting everything from scratch, and have my Java call C++ functions from a DLL that is common to some functional domain.
Does anyone not use these kind of apps? If not, other than writing bash scripts or perl, how do you create extensible, versatile tools to solve your problems?
Perhaps the registry is like what people say about democracy == it sucks, but itâs better than the other forms of government out there.
I just wanted to make sure your discussion covered a large surface of the apps available to run on modern OSes.
JS
As usual, the big problem comes from the complete lack of decent security in windows and the fact that that to get it to do anything you have to be running as an administrator, therefore the application/installer you happen to be running has full access to the registry. If you open up regedt32 instead of the normal registry editor you can see that security access via acls to keys in the registry is implemented, but the need to be admin to install apps means it is rendered useless.
The question is really, why should admin rights be required to install anything other than OS software. (As an aside, why should we have to keep installing OS level software in monthly updates?) Because the security was not thought out and the few attempts to implement it have been counter-productive to the point that now to do anything you get an ugly popup confirmation or ten, which then grants the application/installer full rights to do anything it wants, not just install or run itself. Rubbish.
Unix had the concept of user, group, other from the word go, and DOS came after Unix, and Windows in itâs âNew Technologyâ variant came along time after that. If the originaly designers at Microsoft had even the slightest idea of what they were doing (or the people who MS bought MSDOS off), then things would be a way lot easier for us now. I personally would be about a yearâs worth of wasted man-hours ahead in my life.
MS give me that year back which I have lost due to your crappy design, implementation and marketing/greed-driven decisions I say!
Ultimately I believe the registry was a failure.
Why? Primarily because the state is accumulated through the application of scripts. This leads to a situation where it is very easy to corrupt the configuration.
The alternative? A synthetic view of configuration built dynamically from a set of application manifests. This would allow easier application removal and coexistence. It would also facilitate building security envelope around applications that would shutdown applications that attempt undeclared operations.
c.f. the metabase IIS7, Softgrid
Intelligent discussion about what is really wrong with the Registry seems to be scarce. This is a good start and there are some great comments here! I hope Microsoft is reading.
Iâve worked in some depth with the registry (on the roll-up-the-sleeves, mucking-it-out level) and here is my own list of problems Iâve noticed with it, some of them similar to stuff mentioned in the article and comments:
-
The registry is âstatic.â What I mean by that is that it typically has no provision for dynamic verification or re-registration of anything, because it depends on these babysitters called installers for its information (and makes the dangerous assumption that they are always right).
-
The registry is âsedimentary.â Thanks again to its reliance on installers firing off one-time additions of data that may or may not ever be re-examined, stuff âbuilds up over time,â in layers as it were. To make matters worse, new layers can overwrite previous layers entirely. Meaning: the registry is un-journaled and un-versioned on a granular level, which, given the computing power available today and the long-established practices for doing these things in filesystems and databases, is nothing short of criminal.
-
The registry stores data as âdumb de-contextualized.â It lacks important metadata that it really ought to have if parties beyond the OS are going to be messing around in it, such as information about key creation and ownership, key history or version, dependencies, cross-references, validation constraints, comments, etc.
Many posters have alluded to the way OS X does things as an alternative possibility; here is some factual reading straight from the horseâs mouth on how it does configuration and registration management:
http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/index.html
http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/index.html
Not saying these are the BEST way or the RIGHT way to do these things, but itâs worth looking at for educational purposes.
Whatâs with you weenies and liking XML?
Itâs inefficient! Use YAML.