What is the point of a registry?

[BeauJangles]

I understand it keeps information on what programs are installed, but why are so many other things (keys, settings, etc) kept within it? It seems most of the junk that clutters it could just be contained within the program itself.

 

[Barnaby W. Füi]

its just a unified place to keep program settings which is quickly accessible since it's all loaded into ram when windows is running.

personally i think its not a good way of doing it, first of all it is cryptic by nature, to try to hide things from you, and also because its composed of 2 (i believe) files. if one of those 2 files is corrupted, goodbye registry. i prefer seperate, small, text configuration files for apps. just 'makes sense' to me

 

[NogginBoink]

Bing has the right idea.

Personally, I like the registry idea. It has all settings in one centralized place, as opposed to .ini files scattered all over the hard drive. (I don't agree that the registry is hiding anything from anyone.)

OTOH, the *nix crowd lives and dies by small text configuration all over the place and it works for them. Just two different paradigms, each with benefits and drawbacks.

BTW, under NT4/W2K/WinXP, the registry is composed of more than two files. The files live in %systemroot%\system32\config. Look but don't touch.

Also, you can add as many files to the registry as you'd like!

Not very useful for most folks, but if you're running a cluster server, the hive HKLM\Cluster actually lives in the file c:\winnt\cluster\clusdb.

-Noggin

 

[Barnaby W. Füi]

<< Bing has the right idea.

Personally, I like the registry idea. It has all settings in one centralized place, as opposed to .ini files scattered all over the hard drive. (I don't agree that the registry is hiding anything from anyone.)

OTOH, the *nix crowd lives and dies by small text configuration all over the place and it works for them. Just two different paradigms, each with benefits and drawbacks.

BTW, under NT4/W2K/WinXP, the registry is composed of more than two files. The files live in %systemroot%\system32\config. Look but don't touch.

Also, you can add as many files to the registry as you'd like!

Not very useful for most folks, but if you're running a cluster server, the hive HKLM\Cluster actually lives in the file c:\winnt\cluster\clusdb.

-Noggin >>


i'm in no hurry to disagree with you or anything, but take a look at this pic and interpret it as you will...it is a screenshot i made of some "interesting" stuff i found in the registry.

http://pixicore.org/mackstann/wtf.gif

edit: woah, 160K jpeg, hehe i toned it down to 33k but there are lots of artifacts, oh well

edit again: WOAH way too many artifacts...dammit...give me a minute if its unreadable

ok its a gif

 

[BeauJangles]

yea the registry seems really cryptic to me. It reminds me of something that is left over from the days of DOS. I guess it's kinda good to have everything in one place, but still it's odd how many games/apps use it. For example, many don't store anything but an entry that says hey! I'm at such and such location. They use local files to save most of the ini stuff. Other programs *cough* Half-Life *cough* store everything but the kitchen sink in the registry. If it is intended to allow fast loading of programs into RAM then why not write out a method in which it should be implimented? Also, I don't believe mac has a registry (or if it does it's damn well hidden), macs seem to boot pretty promptly, how do they handle all the ini files?

Thanks for the responses

 

[RalphTheCow]

Does the registry do anything to keep track of the versions of DLLs required by programs? I always thought that was what it was for and thus a good idea, but it seems so cryptic to me, I've never seen that in it.

 

[DaHitman]

The registry is one of those things that "sounded good" in the meeting and looked good on the whiteboard....

But in reality works really crappy.


Storing configuration data in text files like this:

IP_ADDR_NET_CARD_1=10.0.0.1
MASK_NET_CARD_1=255.255.255.0

is much easier to work with, support, admin, and backup than a binary file...

Not to mention the following problems/benifits:

1) Text files can be backed up/copied easily.. The register binary file cant be cleanly backed up while the system is up and running without a special utility.. otherwise you get a corrupted file.

2) ALL YOUR EGGS are in One Basket.. putting EVERYTHING in one file is stupid.. one file one error=worthless hunk of junk on your desk, or in your server rack. Separating stuff into more managable files is nicer.. networking, application configuration etc..

3) Seprate files makes it easier to transfer configration settings. If the configration settings for a particular peice of the system, say a "web server" peice or something is in its own config file, you just have to copy that file to another system and your configurations all are taken with you.. its nearly impossible to do this with the registry.

4) In-Line Documentation...

In a text file you can put comments such as this:
# The IP address goes here
IP_ADDR=10.0.0.0

# The Netmask goes here
NETMASK=255.255.0.0

THERE IS ZERO ability to do this in the registry.

5) Security control. With config files, security is done using simple file system security.. since whatever your security access to the files are is your accees to read/or make changes. The registery has yet another set of security controls, and rules etc.. to maintain... which is diferent than everything else on the system.




BTW, there is nothing that says that config files have to be "ALL OVER THE PLACE"... you could just as easily standardize on a particular set of directories and directory locations and formats like you can the registry... so that's really a bogus argument against config files, since it has ZERO to do with the actual merits of text config files over the registry or vis-versa.

 

[Nothinman]

To overly convolute things and make the system more fragile.

If one portion of the registry gets an error the system won't boot, as many peopel will attest to, and a single point of failure is stupid.

OTOH, the *nix crowd lives and dies by small text configuration all over the place and it works for them. Just two different paradigms, each with benefits and drawbacks.

The only drawback I can think of is that there's no standard format for the config files (which can be fixed, but would take time to convert everything), OTOH I can think of many drawbacks for using the registry.

 

[Oogle]

One use of the MS registry is to maintain a database of programs that are "plug and play" like. This is like winamp plug-ins except they're plug-ins for your OS. A big advantage to this is that ANY program can literally use the functionality of any other program that has been properly registered in the registry. Many of the big software companies design these plug-ins so that other developers in the industry can readily take advantage of them.

The name for this whole idea of sharing software components is called COM (or CORBA). This is why you're able to embed video clips into your word documents, or have "browser"-like interfaces for software applications. If you wanna see how many COM objects are available in Windows, go to the following registry key:

HKEY_CLASSES_ROOT

Under this key you'll some extensions. Go further down and you'll see names using the following conventions:

AppName.ComponentName.Version

Almost all of the keys using this naming convention are COM objects; objects that are freely available for any developer to use. These are only software COMPONENTS, not actual programs. COM programs are kind of like the glue that put these components together.

Without the registry, interchangable components in windows would not exist.

 

[Nothinman]

The name for this whole idea of sharing software components is called COM (or CORBA). This is why you're able to embed video clips into your word documents, or have "browser"-like interfaces for software applications.

unixes use CORBA just fine, as well as sharing software components. Some would argue that shared libraries work better on unix because of the versioning that isn't done on Windows resulting in DLL hell. The registry is supposed to help this, but it's by no means responsible for it.

 

[ShadowWolf]

Well, I think the argument is more of a preference than anything else.

I mean, registry is a great idea -- but like anything needs to be done right.

Look at the creator: MICROSOFT.

If the registry of MS was done right, it would work just as well as the *.inf method.

Niether one is really better if done right -- it's more of a preference.

By the way, the ALL YOUR EGGS IN ONE BASKET thing is not always right. Splitting up your files is often more dangerous than keeping them all in one, same as most anything else.

Besides, the Windows registry isn't dead after 1 corruption, you can still boot into safe mode & stuff

 

[Oogle]

<< The registry is supposed to help this, but it's by no means responsible for it. >>


I never said that a system crippling registry is necessary for every OS to do CORBA (It is necessary for windows). However, UNIX does need a service and a database of some sort to manage interfaces to objects in shared libraries. Without such a database, you lose the transparency between client and object; which is considered a big CORBA plus.


<< Some would argue that shared libraries work better on unix because of the versioning that isn't done on Windows resulting in DLL hell. >>


Shared libraries without CORBA? How would that take care of the hell that is backwards compatibility? One of the reasons windows had DLL hell was because there was no "all-seeing, all-knowing" broker (i.e. CORBA) that managed interactions between client and object. But now it does have it. It's called RPC and the windows registry.

BTW, I love COM/CORBA. Script kiddies can have a field day with it

 

[Nothinman]

I mean, registry is a great idea -- but like anything needs to be done right.

I would say it's 'not a bad idea', but I wouldn't call it a great one. The chance of problems with one system-wide, binary database is too great.

However, UNIX does need a service and a database of some sort to manage interfaces to objects in shared libraries. Without such a database, you lose the transparency between client and object; which is considered a big CORBA plus.

I believe that's what gonfd does with gnome apps, I'm sure KDE has something similar, and I'm sure they both also use flat text files.

Shared libraries without CORBA? How would that take care of the hell that is backwards compatibility?

libsomething.so.5.0 and libsomething.so.4.0, so each app can use it's respective version if it needs to, on Windows too many apps link against mfc42.dll of different versions for the number to mean anything. And unix people are much better about maintaining backwards compatibility in minor revisions.