Registry vs. other operating systems ways of storing system settings

[Zebo]

I understand the registry is a database for storing all sytem settings, keys, values and other stuff about your computer. (thanks modus) Also, it seems to get corrupted which leads to system "rot" over time and is very complicated to navigate and diagnose problems. Why is this? Is it a faulty design to begin with? And why would Microsoft have such a complicated and buggy way to do things.

What do other operating systems such as solaris, UNIX, OS X, and Linux use for a "registry"? And why is what they are using considerered better by most experts when reading articles about competeing OS's? I

Thanks

 

[pm]

There have been some interesting and heated exchanges over implementing a form of "registry" for Linux. I remember reading them and the two opposing sides were literally miles apart on the issue. And very few stayed in the middle - either you thought the concept of a registry is a wonderful way to condense system configuration data into one file, or you thought it was a terrible idea that made remote configuration a nightmare, and introduced reliability issues.

I'm sure those debates are somewhere out there on the Net. Here's one article that talks about the Unix and Windows methods. It's from a Unix vendor, so you get a one-sided view, but it's worth reading. Then search through the Linux developer mailing list (the kernel one, I think) for registry to find the debate that I mentioned.

 

[DuffMan]

The registry was made because everything in windows used .ini's and they allowed for user errors too easily. So they made the registry which is faster, harder to screw up, and easy. It gets corrupted because it was meant to be fast not redundant and so drive errors show up on it more than anything other. If on a pic one pixal changes it hex color value by one will you notice it?

 

[Armitage]

The idea of a registry sounds good if implemented right. One problem that I see is the amountof crap MS tries to put in theirs. There was a thread in the OS forum a couple of days (weeks?) ago on where IE keeps the url line history. Somebody spoke up and said it was in the registry for each user. Why would you put that kind of data in the registry? What does it have to do with system configuration?

 

[Nothinman]

Why is this? Is it a faulty design to begin with? And why would Microsoft have such a complicated and buggy way to do things.

It's not a terrible idea, but it's very bad implementation. You can have a binary file and not have it get corrupted as easily as the registry does, MS seems to make convoluting and complicationg things for no reason a high priority.

What do other operating systems such as solaris, UNIX, OS X, and Linux use for a "registry"? And why is what they are using considerered better by most experts when reading articles about competeing OS's? I

Most unixes use flat text files for configuration, each program has it's own text file in /etc or /usr/local/etc (if you compiled it from scratch). OS X has a NetInfo database that is sort of like the registry, and it's most annoying because the text files are there for single user mode but the database is used in multiuser mode.

either you thought the concept of a registry is a wonderful way to condense system configuration data into one file, or you thought it was a terrible idea that made remote configuration a nightmare, and introduced reliability issues.

remote management with text files is simple and that's great, but a registry wouldn't have to break that. You could have a set of nice CLI tools to mange the registry remotely (or locally if you don't like the GUI tools or want to script things). But the reliability issues are the real ones, I mean look what happens when the software hive gets corrupted in NT, which happens more frequently than you'd think.

The registry was made because everything in windows used .ini's and they allowed for user errors too easily. So they made the registry which is faster, harder to screw up, and easy

The registry was made so they could have a single interface to all programs settings and things, which on paper sounds good, but since MS forces no conventions on people they can just add keys wherever they want and if a problem occurs you just broke all your software instead of one program.

And if the registry was easy and harder to screw up, there wouldn't be a warning in every MS Q article about how mis-editing the registry can totally kill your machine.

The first time you see a NT box (NT 4, 2K, XP, etc) not boot because the system or software hive is corrupt, you'll realize why unix's small, simple text files are a very good thing.

 

[jasonroehm]

Amen, Nothinman. One of my Win2K boxes kept losing the Software hive about every month or so. I don't know if it was some sort of virus, or if my luck was just that bad on getting a bad part of the disk. It was maddening, as I never really kept backups of my registry, so I usually had to just reinstall. After the third time or so, I formatted, did an fdisk /mbr, and everything has been great ever since.

 

[Nothinman]

I formatted, did an fdisk /mbr, and everything has been great ever since

fdisk /mbr shouldn't affect that at all, all it does is replace whatever MBR you have with the default DOS one, if you were able to boot up before this did nothing.

 

[Zebo]

Thanks nothinman,

So basically.

Registry-
-one file with a directory type structure
-multipile entries for one value,key etc. (which are hard to find and edit)

Unix "registry"
-mutiple text files like windows 3.1 had

 

[Nothinman]

More like 'like unix has' because Windows came out way after the first unixes did.

 

[Locutus4657]

More like "Like DOS Had" because Windows 3.1 was basically a DOS shell anyway... At the time just about everyone managed the system/software with text files...

 

[CTho9305]

my thoughts:

how about a registry-free OS where every application keeps its plain text rc/ini in its own directory?

advantages:
if the OS breaks, all the programs dont lose their config
one broken app is unlikely to create havok throughout the system
to add/remove an app you need only create/delete the one directory with files

disadvantages: man would be difficult to implement since apps would ONLY exist within their directories. same for a "start menu" kidnd of thing.

solution:
each app that needs to know about other programs has a file to which other programs can write to. this would require a standard.... lets say I install some software, it would look for man and then let man know it exists and where to find the man page in man's config.

problems:
what if you want to install somehting out of its standard location?

solution:
a small central registry. would contain: one "key" for each program. wihtin the key would be the program's location. that would be the limit of what is allowed in the registry.

sound good/bad?

so, here is what each OS does wrong:
windows: keeps too much in the registry - single point of failure destroys everything. apps do tend to keep most of their stuff in the right place.
*nix: apps are all over the place: a config file in /etc, some binaries in /usr/bin, man pages elsewhere...
macOS X: dont know. I dont like the backend directory structure very much, but they did a good job otherwise.
macOS pre-X: doesn't count as an OS.

it occured to me that this still might leave a problem for dynamically-linked libraries, but they should be treated as independent programs - with their own registry entries. their entries would also have to have a list of which programs are using them.

One problem that remains is that upon the uninstallation of programs by manual directory removal (vs. a pretty uninstaller program), registries would not necessarily be updated. you'd need a cron job that check everything occasionally and removes invalid entries.

 

[Fandu]

I think the registry idea CAN work. But what we need are alot stricter controls on where and how many keys programs can place in the registry. My registry is a touch over 50MB right now, that's frikkin BLOAT.

Maybe the system registry and the program registry need to be split apart. That would help protect the system settings, and at the very least the system should always be bootable.

 

[Nothinman]

Maybe the system registry and the program registry need to be split apart. That would help protect the system settings, and at the very least the system should always be bootable.

They are already, but the system needs all of them to be loadable to boot. Look in C:\WINNT\system32\config, the files with no extension are the registry hives.

The thing I want to know is why everyone thinks a binary registry is a good idea? Text files work just fine and are a lot easier to recover from when they break.

 

[ShadowWolf]

Well, I personally am a Registry Proponent. The reason is the uniformity.

Let's not consider Microsoft to be running a proper registry because they aren't.

A registry, when properly done, is more similar to a small version of a filesystem. It acts by holding the values and necessary components of Applications in a centralized location layed out in a commonly used directory structure ( Personally, I would use a *NIX style fs with a shell browser ). Navigation would be in a shell layer system. Each application would be able to include a regedit header file or acess to the regedit API settings which would ONLY offer access to create and destroy. Applications would NOT individually write to the registery as they do in Windows, but rather would send it to the registryfs which would write the data. Also, complex dir structures would NOT be allowed, and the fs would be more of a MS-DOS system, with an 8 character name and a max of 5 subdirs.

At this point, we would split the registry into a few components:
KernelReg
AppReg
SysReg
BootReg

BootReg would be like a registry that gives boot-time values and points to the other Registries.
AppReg & SysReg would store Application and System registry values ( software ONLY ).
AppReg is the ONLY registry accessible without ROOT access or by the KERNEL.
SysReg & KernelReg hold system and other crucial data.

The reason one would NOT merge these is corruption, which occurs with Windows. Windows has seperate hubs which are merged together to form one huge registry. Great in theory, but anyone who understands the FAT/NTFS fs knows that constant data shifts cause fragmentation. This basically leads to registry corruption etc..etc..

going further, the reason one might consider a registry over text files is size. A registry can use an fs specifically designed for the registry where the inf files suffer from the larger fs scope of a standard fs such as ext2, HPFS, or NTFS. They may be efficient, but large files require larger minimum cluster blocks, whereas a registry could simply have it's own VERY small partition ( similarly to how Linux uses a partition for SWAP instead of a file-on-disk ). In a proper journaling filesystem, this may not be necessary.

The power of registry also lies in it's ability to force conformity. By utilizing base binary datatypes, one can minimize the size and maximize the power and speed of the registry.

 

[Nothinman]

I don't want to sound like a broken record, but the thing noone has been able to say is why a binary registry should replace text files like unix still uses? What is so bad about them that makes everyone want to use a hard to recover, hard to use, inflexible, un-human readable format?

 

[Fandu]

Nothinman:

I don't know all of the reasons, but a major one is that a binary registry is ALOT more compact. Instead of a 50MB text file, you could have a 5MB binary file. Now because you have reduced the size that much, the chances of corruption have also decreased.

 

[Nothinman]

I don't know all of the reasons, but a major one is that a binary registry is ALOT more compact. Instead of a 50MB text file, you could have a 5MB binary file. Now because you have reduced the size that much, the chances of corruption have also decreased.

First of all I'm not talking 1 text file, that would be dumb. Second on one of my Linux boxes my /etc dir is ~5M, on my Win2K box my registry is (as reported by Winows, not actual files sizes) ~15M. Even if you add the config files in my Linux home directory I doubt you'll come close to 15M.

And third, just because a file is big doesn't mean it's prone to corruption. If your OS continually corrupts large files when smaller ones stay healthy something in your VM, filesystem driver or in between is badly broken. For instance, I have a 163M mail file (the way basic Linux mail works is each 'directory' is a big text file with all the messages appended end to end) and it has never gotten corrupted simply from using it. Using your logic I should split that up into 10 files so it can avoid corruption :/

 

[CTho9305]

IMHO a compressed registry has more additional risks than a large ascii one... the compression and decompression are vulnerable. if the system goes down while writing a compressed file, EVERYTHING dies. a text file will leave some data intact, and multiple text files will leave everything but the one file in a useable state.

I dont understand why people like having programs sprawled all over the place though rather than each in their own folder.

 

[Zebo]

<< More like 'like unix has' because Windows came out way after the first unixes did. >>


LOL. I knew you would say that.



<< I'm sure those debates are somewhere out there on the Net. Here's one article that talks about the Unix and Windows methods. It's from a Unix vendor, so you get a one-sided view, but it's worth reading. Then search through the Linux developer mailing list (the kernel one, I think) for registry to find the debate that I mentioned.
Q]

Great link there pm which desipte being from a Unix provider seems pretty factual and informative.

 

[Nothinman]

Since I missed the linked article the first time I'll comment now =)

Microsoft provides tools to maintain only parts of the registry. IIS 3 was a good example where there were many more registry entries than there were options in the Internet Manager

MS always has a lot more configurable options in the registry than they allow changed via the GUI tools. This isn't necessarily a registry problem per se, but the registry definatley makes it a lot easier for MS to hide those keys where you won't find them.

It also provides two limited editors as the only general purpose access to the registry and says it's can't be responsible if these tools are used, even though they are often the only way to maintain parts of the registry.

How often do you see a warning on a web page where you're told to edit a text file with notepad? It's true that I can misedit a file bad enough on unix to make the system not boot, but it's also trivial to boot to a rescue mode or CD and fix the file, if you make a registry edit that causes Windows not to boot, try fixing that.

If a registry key contains spaces, and many do, the limitations of the command line interface may provide no way to pass the necessary arguments to the utility

This is generally wrong, all you have to do is enclose the name in quotes and it'll work fine, unless you're using a 3rd party tool that's broken. I know we've used MS' reg tools in the NT 4 and 5 resource kits on keys with spaces in quotes.

The registry has no equivalent of create, modify or access times so it's not possible to locate recently changed registry entries or to relate modification times to the onset of a problem.

I've never thought of this, but it wouldn't be a bad idea. It would be nice to be able to look for keys created/changed on a certain day at a certain time.


There's a lot of 'why the registry is bad' information out there, some of it factual some of it opinion, but I have yet to see anyone lay claim that the registry is a really good idea. Everyone seems to agree it's bigger, slower and easier broken, so why keep using it? The only reason I see MS still using it is because they developed it (and they have a big 'if it wasn't developed here it sucks' problem) and it would take a big effort to convert NT away from it.

 

[ShadowWolf]

Umm...perhaps my post is invisable.

Happens a lot with me, did I explain something too vaguely?

 

[Nothinman]

Umm...perhaps my post is invisable.

No, not at all. I just don't think you can force uniformity on programmers, they will all always want to store their settings slightly differently than the rest as long as they can choose the key names, etc.

And if you force them to use 8 char names and only 5 dirs deep it'll just make things uglier because the registry will be filled with abbreviations that only mean something to the person who put the key there.

I just don't think the benefits of a binary registry out weigh the benefits and flexibility of directories and plain text files.

 

[ShadowWolf]

Soo...the entire time we were using 8.3 conventions in our OS's they were abbreviations no one could understand? I was never aware of this ( I grew up on DR-DOS ( Caledra/Open DOS ) and MS-DOS ).

Uniformity is used all the time, just people don't realize it. For example, the uniformity in Comments in programming languages, conventions, piping in an OS, all of those work in very similar manners.

Give an 8.3 file format, you can easily explain just about any key you can think of. It's unnecessary (and a waste of space) to use something such as: MaxRCVWindow when a variable called RCVWndow put in a dir called TCPIP that's located in Eth0 which is in Networks would adequately describe the command you wish to set.

But the point is not their key names or something like that, but HOW they store it. Take, for example, your text files. People don't use (from my findings within Linux) ANY form of uniformity AT ALL. But the MAN pages are done in a very specific way and people GLADLY follow that format. Similarly, in a well-done registry, you could have a comment link to a text help file. Such as Hlplnk which is a DWORD to the help.txt file stored someone on the HD. There's no reason why something similar couldn't be implimented.

I see your point about text files, but I really do not like them because they are that: Text files. It would be easier to be given a set of keys that are short and to the point. No true parsing necessary ( for comments & what-not ). There are infinite ways you could make the registry as well!! You could make it all asm calls, binary, C++ Code, BASIC, or whatever you want. That's the wonder of the registry, it's THAT open because no one has made a proper registry.

Besides, binary is often far faster than a text file, and 10 character names wouldn't make too much of a difference either, just 2 bytes more. I say 8, though, because it's a well-rounded number.

 

[Nothinman]

Soo...the entire time we were using 8.3 conventions in our OS's they were abbreviations no one could understand?

Not for every single instance, but for a good bit of them.

It's unnecessary (and a waste of space) to use something such as: MaxRCVWindow when a variable called RCVWndow [/I[

What if I mean RCVWndow to hold the last negotiated recieve window, not the maximum allowed which is probably a defined constant anyway? I may know that, but you won't.

But the MAN pages are done in a very specific way and people GLADLY follow that format.

man pages have to follow a certain format, otherwise they don't work, just like RTF docs have a defined format. And not everyone follows that format, infact the GNU guys publish all their docs in 'info' format and publish man pages that say 'for the full documentation read the info docs'.

I see your point about text files, but I really do not like them because they are that: Text files

Personally I like them for that very reason, I can use any editor to change them, I can copy them around without worry about them not working on another system (i.e. different endian arch), I can put comments in them to explain why I have a setting a certain way, I know for a fact any version of an editor will work with my files, etc.

Parsing text files may be a little slower than reading a binary file (although on a recent machine you'd be hard pressed to notice), but to me it seems the problems with non-human readable files out weigh the benefits.

 

[ShadowWolf]

But why would you store a value like the last recieved window in the registry? The registry values are designed to be mainly constant, with some semi-dynamic variables in them. Things that rarely change from boot-up to boot-up. A value like the last recorded recieved window value should be stored in a log file or something of that nature, it has no business in a registry.

That's another thing, all registry values should be as close to constant as possible, in that during the session of the OS those values are non-changing. Having it so they only change on the boot of the OS helps a bit, but that's annoying.

Realize that I see Microsoft's attempt at a Registry as a failure. If I finish my OS, you'll see what I think a registry should REALLY be like.