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?
Best Answer
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.