Re: Why a registry? (was RE: Binary Dist (setup program)for Win32)

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.