Why is Windows registry needed?

Question

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?

Answer 1

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 (or, arguably, a network database if you take symbolic links into account). 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.

Answer 2

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.)}

Answer 3

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.

Answer 4

My theory is the driving force is none of the above. Rather, it was an 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.

(2014) To expand upon my reasoning here a little bit: I see the registry as a god object. We all know that's an antipattern.

Answer 5

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).

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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...

Answer 10

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.

Answer 11

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!

Answer 12

(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.

Answer 13

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.