|
On Wed, 10 Apr 2002, Dan Bale wrote: > This is a wee (way?) bit off topic, so please indulge me. > > It seems that, nowadays, we tend to clamor for applications that DON'T touch > the Windoze registry. I know I am more willing to try out an application > that doesn't touch the registry. What did the registry really buy us > besides utter frustration if/when the registry ever got corrupted? The registry is just a database where the programmer can store things -- pretty much anything, in fact -- so your question is a little strange to me. What does a database buy us? A quick and easy way to save and retrieve information. The registry is usually used to store program settings, as well as a place to look for operating system settings that might affect our program. This is a useful thing. The particular implementation that Microsoft chose was poor, however. The buggy API that's used to read/write the registry runs a risk of corrupting it. In the DOS days, you could just copy your program from folder to folder or drive to drive and run it from the new location. This was convienient because when you ran out of disk space, you could re-allocate it. When you wanted to organize things, you could do that... it was easy. The registry complicates this because programmers will hard-code locations and relationships between programs & files in the registry. This is, IMHO, a mis-use of the registry -- and probably isn't the registry's fault, but the programmer's fault. Of course, if Microsoft had used a more intelligent file system, it wouldn't have been an issue. You would be able to add on another drive without having to totally change where everything is located. Both OS/400 and Unix are much more sensible in this regard. The real problem with the registry is that it's used for EVERYTHING, both data that's critical for the operation of the OS itself, and for data that's useful only to specific applications. This is a problem because programs will (sooner or later) have bugs that screw things up. It should not be possible for an application to mess up the system's settings to the point where the system can not function. So, the idea of a registry isn't a bad one, but the Windows implementation of it is awful. > having to manually edit the cryptic registry because the uninstall program > didn't work? (That's happened to me more times than I want to remember.) You have to remember that commercial software is driven by money. Having a really good uninstall program doesn't help a software company sell software or make money -- consequently they don't put as much effort into making their uninstall programs bug-free. But, again, the really big problem is that you can mess up the operating system with your bugs. OS/400 has separate system domain and user domain objects -- user domain objects can't mess up system domain objects. That's a good thing. In UNIX, you have a separate /usr/local area of the disk, and object security is used to prevent you from messing with the system area of the disk. Windows however doesn't care... you can do whatever you want in Windows. You even store your DLL's in the same directory as the system's kernel modules. > The other, somewhat related, thing I've never figured out is why > applications that supply their own DLL's, that no other app will ever use or > know about, have to put those DLLs in the Windows folder? Why don't they > just keep it in their own folder? Not all of them do... but many do because programmers write utilities that they think are supremely useful, and they want them globally available... and since every programmer has his own set of these, you end up with a billion DLLs. And since Microsoft recommends that DLL's go in \windows\system, they put them there... and bad uninstall programs cause them to remain there forever. > > Is this all strictly a Windoze "feature"? Or do other OS's have to deal > with this, too? Yes... all OSes have to deal with this. Just most of them do a better job! Misc user programs can't add their own random system values into OS/400's system value list, so you don't end up with megabytes of system values that nobody can figure out. :) Install/Uninstall info is kept everywhere. In FreeBSD, they use a /var/db/pkg directory, and then a seperate directory for each package. This way, if you remove a package improperly, you can remove the directory with the package info. Then, scan the other packages to see if they have dependency info. RedHat (and probably some other Linuxes) use the RPM system to keep track of install/uninstall info. I have only limited experience with it, but I haven't had any problems. But, the kernel itself does not rely on this database for the OS to function! The database doesn't store everyone's everything, but just stores the install/uninstall info. It's just a better implementation.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.