O.T removing unwanted registry entries

[Rich Grise]

Windows attempts to use its registry for something not supported (in
this manner) in *NIX systems. That is, tracking dependencies between
various components like libraries (DLLs in WindowSpeak). [...]
An uninstall is (theoretically) able to detect whan a DLL becomes
'unused' and suggest that it be deleted as well. There is nothing more
frightening to a novice user than the box that pops up which suggests
deleting one of these, with a hint that doing so might damage the
system.

Keeping track of the "dll"s could be done in other ways and I suspect
about half of them would be better than using the registry for it.

Windows has to process the whole thing at least once per system boot.

You only really care about the use count when you go to remove a program
or perhaps replace a dll.

Linux doesn't have this problem - each version of the libraries has its
own version number, so when you install something new, if it uses a new
version of a library, it just puts it in /usr/lib alongside the old one,
and each program knows which version of a given lib it needs.

Cheers!
Rich

 

[Mark]

xyzzy eh

that's was quite an adventure?



Mark

 

[Paul Hovnanian P.E.]

Interesting.

That would seem to work only for DLLs loaded at program-load time,
though, not ones loaded explicitly by the program. I'm thinking of
things like user-supplied extension DLLs, which you typically tell the
program about on the command line or in some config file. Here's a case
in which the Windows approach (wart-encrusted though it be) seems
superior. Deleting a DLL that's loaded explicitly in some other program
will cause massive breakage.

The described cleanup does need to be handled with care. Usually, a
report is generated and the administrator skips the application-specific
components.

Perl works this way, having numerous modules that are loaded during
program run time. Typically, these are kept separate from the system
libraries.

 

[Ken Smith]

You only really care about the use count when you go to remove a program
or perhaps replace a dll.

Linux doesn't have this problem - each version of the libraries has its
own version number, so when you install something new, if it uses a new
version of a library, it just puts it in /usr/lib alongside the old one,
and each program knows which version of a given lib it needs.[/QUOTE]

Yes, I know. I am typing on a Linux box right now.

There are still a few problems that need to be solved on Linux boxes.

(1) The installs for Linux apps often test for the correct library already
being there and bomb if it isn't. They don't produce a list of what needs
to be added to the system in some nice text file so you tend to end up
installing one of the three things that are needed and trying again to
find out the next one.

(2) Things like the latest "gcc" should also have a fully statically
linked version published too. I had a problem some time back where "gcc"
would not install without a new "glibc". The "glibc" had to be compiled
with "gcc". It would not compile with the old version of "gcc". There
was no way forward but to find a new install with both on it.

(3) The linux comunity needs to get together on what "compatible with" or
"for" means. To my view, if you take new hardware and the CDs for XYZ-9.2
linux and make a system, you should then be able to install a program that
is "compatible with XYZ-9.2" with nothing else needed.


I switched to Linux at work because I could have either XP or Linux and
needed to run some DOS apps. The DOS apps work better under Linux.

At home I use Linux because I figure it is the trend of the future.

 

[Ken Smith]

xyzzy eh

that's was quite an adventure?

Yes, some days you are in the pump house and others you are in a twisty
maze of tunnels that all look alike.