Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As I have debugged problems in com, side by side, dealt with dll hell, all while hating the windows registry with passion, I was wondering why is it needed.

I never felt compelled to read an entire book on registry best practices, and then just "get it".

I have, however, used Linux and Mac OS, and look at the ways one can install multiple versions of Python and its libraries on the same *nix computer.

Because registry has somewhat of a free (albeit ugly) format, and is used for all sorts of purposes, I have never understood what essential problem it is trying to solve.

For instance, Microsoft does not want you to have two different versions of MS Office installed side by side. They use registry to enforce this during installation. This limitation is artificial, in my opinion. If they really cared to allow a different behavior, they could have adjusted their architecture accordingly.

In Mac OS you can install and remove apps by just dropping them into a particular folder.

So,

A) What essential problem it is trying to solve? B) How do other operating systems solve it?

share|improve this question
7  
Good question. I'm looking forward to reading the answers. –  Anna Lear Feb 18 '11 at 16:43
1  
Applications can be installed by Drag-and-drop on Windows as well. The Eclipse IDE is the first example that comes to mind. There are others, I'm sure. The registry is also used to configure many other aspects of the operating system (I always thought that was the primary purpose of its existance) and other programs, and can also be abused in all kinds of interesting and creative ways. –  FrustratedWithFormsDesigner Feb 18 '11 at 16:45
2  
See en.wikipedia.org/wiki/Windows_Registry –  Jonas Feb 18 '11 at 16:54
2  
You can have two versions of office installed so the "limitation" you mention isn't just artificial its fictional –  Conrad Frix Feb 18 '11 at 20:27
1  
@Job. I guess I could agree on that except for that fact that the problem has an accepted solution, a registry fix, (irony not lost) which refers to running 2007/2003 side-by-side. When did you experience this problem where you wanted run two Office installs side by side? BTW here's the KB For running XP and 97 side by side –  Conrad Frix Feb 18 '11 at 20:40
show 3 more comments

13 Answers

Most of the other answers are more or less correct, but (along with the question) they kind of miss the point.

The registry is a hierarchical database manager -- nothing more and nothing less.

The "faults" you're attributing to the registry are really independent of the registry itself. They're simply decisions various vendors have made about things like how to install their programs -- if you stored the information in some other fashion/form/container, the same problems could remain.

Given the "everything is a file" philosophy of Unix, it's (or should be) no surprise that Unix (and similar, such as Linux and MacOS) systems store the information as individual files in the file system. This isn't nearly as different as many people might immediately believe though, since the Unix file system is itself a hierarchical database. The glaring difference is that the registry is accessed via a separate API, where storing configuration data in files allows those files to be accessed, edited, etc., via the same API (and tools) as any other files.

share|improve this answer
3  
    
@Jerry Can you elaborate on your claim "the Unix file system is itself a hierarchical database". I can't find any documentation that makes it seem any more like a DB than any other file system. (e.g. supporting a query language or ACID transactions ) –  Conrad Frix Feb 18 '11 at 20:01
    
@Conrad I think for the purpose of Jerry's answer "database" is a loose analogy. The filesystem itself is not a query language/ACID database, although I'd expect (assumption since I haven't used them) that the APIs for storing preferences in Unix/Linux/MacOS would wrap the filesystem to give it ACID properties. –  NickC Feb 18 '11 at 21:08
5  
@Conrad Frix: what makes you think ACID transactions or a query language is necessarily part of a database? –  Jerry Coffin Feb 18 '11 at 21:30
1  
@Jerry, of course. I agree with you there. But (as evidenced by Conrad's comment) many are inclined to assume certain things about the properties of something called a "database", so I guess my attempt at mediation is just a lose-lose. –  NickC Feb 18 '11 at 21:43
show 10 more comments

It's a Settings Repository - a centralized and somewhat standardized location for preferences, settings, lightweight profiles.

It becomes easier to understand when you look at the big picture for all things an OS has to store for its users and applications:

Windows

  • Settings Repository
    • System: Windows Registry HKEY_LOCAL_MACHINE and specifically much of it is in \SOFTWARE\Microsoft
    • Third-party system-wide: Windows Registry HKEY_LOCAL_MACHINE
    • System user-centric: Windows Registry HKEY_USERS, [user]\SOFTWARE\Microsoft
    • Third-party user-centric: Windows Registry HKEY_USERS\[user]\SOFTWARE
  • Application files a user shouldn't need to see C:\Users\[User]\AppData in hidden folders
  • Application files a user may want C:\Users\[User]\ in non-hidden folders created by app

Mac OS X

  • Settings Repository
    • System and third-party: /Library/Preferences in com.apple...plist files
    • Third-party system-wide: /Library/Preferences in third party plist files
    • System user-centric: /Users/[user]/Library/Preferences, same as above
    • Third-party user-centric: /Users/[user]/Library/Preferences, same as above
  • System-wide application files a user shouldn't need to see /Library/Application Support
  • Application files a user shouldn't need to see /Users/[user]/Library/Application Support
  • Application files a user may want /Users/[user]/ in non-hidden folders

Essentially, the registry is identical to Mac OS X's /Library/Preferences folders, and not much more or less.

The fact that Mac OS has a near one-to-one match for organizational groups of system and application data illustrates that the Windows Registry is a completely justified system that is just a different way of doing things

The non-file-system nature of the registry does make it harder to back up, restore or migrate parts of it while leaving others, so I do prefer the Mac system, but the purpose is nearly identical.

Both OSes have applications that choose to violate these structures to different degrees, usually through the usurping some more global context to create files or folders in that don't really belong there. Some applications actually create folders straight into C:\ or / without asking. That really drives me crazy!


By the way, while the drag-and-drop nature of (most) Mac OS Applications is brilliant, you have a similar problem with different versions side-by-side, though you probably don't notice - since your settings are not stored in the .app file itself, but in Application Support or Preferences, every version of the application will still use the same settings and affect each other, unless the newer version explicitly decides to use a folder by a different name (IntelliJIDEA70, IntelliJIDEA81, etc.)

share|improve this answer
    
True, the registry originally started out as a settings repository, as a replacement for INI files, however these days, it is often used as a general data storage, hence the bloated hives. –  Synetech May 31 '11 at 18:19
add comment

I have never understood what essential problem it is trying to solve.

Prior to the Registry Windows used .INI files. In the blog post Why are INI files deprecated in favor of the registry? Raymond Chen enumerates the problems that existed with .INI files that were trying to be solved. He also enumerates the problems the that XML configuration files share with the old .ini files. This is probably what's worth looking at since that's what a lot of applications use today.

...the pendulum has swung back to text configuration files, but this time, they're XML. This reopens many of the problems that INI files had, but you have the major advantage that nobody writes to XML configuration files; they only read from them. XML configuration files are not used to store user settings; they just contain information about the program itself. Let's look at those issues again.

  • XML file security is not granular enough. But since the XML configuration file is read-only, the primary objection is sidestepped. (But if you want only administrators to have permission to read specific parts of the XML, then you're in trouble.)
  • Since XML configuration files are read-only, you don't have to worry about multiple writers.
  • XML configuration files can suffer a denial of service. You can still open them exclusively and lock out other processes.
  • XML files contain only strings. If you want to store binary data, you have to encode it somehow.
  • Parsing an XML file is comparatively slow. But since they're read-only, you can safely cache the parsed result, so you only need to parse once.
  • Programs parse XML files manually, but the XML format is already locked, so you couldn't extend it anyway even if you wanted to. Hopefully, those programs use a standard-conforming XML parser instead of rolling their own, but I wouldn't be surprised if people wrote their own custom XML parser that chokes on, say, processing instructions or strings longer than 70 characters.
  • XML files do not have a size limit.
  • XML files do not have a default location.

All of this assumes that application do indeed never write to their configuration files which I'm not in agreement on but that would make things worse not better.

share|improve this answer
1  
It is at least a little ironic that many apps are completely forgoing the registry altogether now in favor of INI files again (not so much with XML) thanks to the increase in popularity of “portability”, itself thanks to flash drives. –  Synetech May 31 '11 at 18:21
add comment

My theory is the driving force is none of the above. Rather, it was a anti-piracy measure. In the pre-registry days you could generally simply copy a whole program from one machine to another. Find the .DLLs and you were good to go. The registry makes this MUCH harder to do.

There is very little that the registry accomplishes that I think would not be better served by one configuration file per purpose.

share|improve this answer
1  
+1: Hmm... Interesting perspective. –  Jim G. Feb 19 '11 at 16:53
5  
So microsoft created something specifically to limit what users could easily do?... sounds about right. –  dan_waterworth Feb 19 '11 at 20:03
add comment

My crude understanding is the the registry was designed to be a sort of settings repositry, supercerding the .ini files that used to be used.

(NB, a crude understanding, so this might well be incorrect).

share|improve this answer
add comment

A) I agree with Tim answer.

B) Other operating systems use other methods of storing program settings, for example, Unix's usually place files in /etc (global files) and in the user folder in various hidden folders (user settings). So they all use some form of registry, except that in some cases it is distributed.

share|improve this answer
add comment

As I understand it (not necessarily enjoying it)

A) To give a "centralized location" where any program can store information about its installation or setup. This info can then be used by the programs any way they decide. Customization, anti-piracy, etc.

All this information being in this structure kind of protects it, think of the idea of animals flocking together, more safety in numbers. If each bit of info was its own ini file then some user could potentially delete it on a whim. They can still do that by getting into the registry but many view it as kind of a black box and won't touch it for fear of breaking their system.

B) Mac OS uses individual files much like the ini files windows used before the registry came along.

share|improve this answer
add comment

The obvious purpose of the Registry is to act as a single repository for all configuration and setting data and remove the reliance on configuration files.

On other operating systems, the modus operandi is to store application-specific information (like configuration files) into hidden application-specific directories in the users' home directory. (For example, the game Aquaria stores configuration information in $HOME/.Aquaria.) Global settings files are stored in /etc/.

Macs do their own thing: application-specific plist files are stored (I believe) in the user's or system's Library directory.

share|improve this answer
add comment

The issue is not with the philosophy of registry but with it's design. The registry is used by the OS to lookup important information regarding the program being loaded. Though rather than loading the information as and when needed it loads it all at boot time, which "can" affect the performance of the system. The system is also thoroughly abused as vendors load it with a bunch of information and a lot of times they don't remove the information when the software is uninstalled.

Unlike Unix where everything is stored n files and loaded as and when needed. The OS in this way does not rely on the Vendor programming skills to affect it's performance...

share|improve this answer
add comment

(all A. Not sure about B)

I believe this is actually down to the (historical) point that the registry acts as a kind of common interface for application settings.

Have an application? Want to store a user-scoped setting? Bung it in the registry.

No need to "ensure user profiles", no need to directly access the file system at all. Win32 looks after all that.

share|improve this answer
add comment

While I can't comment on other operating systems, the registry also helps maintain the configuration of an application during an upgrade or uninstall/reinstall process. If all the configuration was in an .ini file that needed to be replaced due to an upgrade that added features, you might run into difficulties, or have to create a customized process in order to merge configuration data into the incoming ini file.

However, with the data in the registry, you can use a common installer package (WIX, InstallShield, etc.) that will handle the uninstall/reinstall of files without touching application settings.

share|improve this answer
add comment

It was a way to create something new, unfamiliar and taboo to most users, so they would leave it alone. .ini and autoexec.bat files can easily be deleted or changed for the worse.

Changing the Registgry Settings, oh my!

share|improve this answer
add comment

In addition to simply storing application settings, the registry is the means by which programs and components locate other programs and components. Ultimately, I think this is why its centralized into a single database as opposed to spread across thousands of text or xml files.

For example, a component that performs, say, video effects 'registers' itself in the registry, allowing other video related applications to know of its existence and use it. By having a centralized system for this, it avoids what would be serious mess as thousands of systems and applications use different methods to achieve that level of integration.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.