Re: MS gets creamed!

Rachel Polanskis (rachel@juno.virago.org.au)
Fri, 24 Oct 1997 12:28:06 +1000 (EST)

Richard Welykochy writes:
>
> Good point. But! There is an inherent weakness in all installation
> mechanisms I've seen where the O/S relies on dynamic libs.
>
> 1. On Unix, an application install generally does NOT overwrite
> crucial system-wide DLLs, like the shared C libs, kernel libs.
> This of course would wreak the havoc mentioned by the original
> post re: MVS. And of course, if you are not installing as
> root, you cannot overwrite the crucial files anyway.

(little bit techy stuff here!)
Within UNIX, you can install private copies of your shared library
in a non critical location, and then force that version of the library
to be used via an environment varialbe (at run time) or a special
linker directive (at build time)
Or you can make a "symbolic link" to the library, and give it
a special name or location that either overrides a preexisting library
or replaces it. An example of this is the Motif library distributed
by Adobe's Acrobat for UNIX. It keeps a provate copy of this lib for itself,
in spite of the system one already being there. This allows a consistant
environment for the application to run with.

> 2. On Windows, an application CAN install over top of crucial
> system DLLs. We all live with the consequences: suddenly,
> encryuption no longer works, or some aspect of the Windows
> visual controls (3D controls are a good example) stops working.
> The real culprit here is older installs that blithely replace
> new DLLs with old.

Windows installers seem to have no concept of the private library of objects,
and all system files and many app specific files get installed into the
"public" OS areas \windows and \windows\system.

An (annoying) example of this are Visual Basic programs, which seem to
deposit private app specific files into the public system area.
It would seem that the VBX libraries proliferate excessively-
if you install lots of software, you'll see many VBX or similar
extensions. This is just silly! Private libraries would be easier
to maintain/replace/upgrade and keep track of if they were installed
in the private applications own directory.

Also, the windows environment itself slows down considerably, as you add more
software, because all these programs dll files are loaded at start time,
instead of being loaded and unloaded dynamically as needed as in other OSs..

This explains why windows gets slower over time (months), it's because
you keep adding software that adds libraries, that windows has to process.

> BTW: almost EVERY invocation of "Remove Programs" that I have
> run under Win95 does an incomplete uninstall, and reports:

One very important piece of philosphy I have learnt (from my learned
and esteemed partner ;) is to consider that *any* Operating System
is like a rainforest.

It is an eco-system and a status-quo that is established between software
that must co-exist with each other.
If you introduce canetoads into a rainforest,
the result is an upset of the balance in the ecology.
The same can be said of the fragile Operating System environment.
Adding a whacky device driver, or an obsolete version of a system library,
or even a utility that does weird hardware level things can completely
upset that ecology, and cause a malfunction. No matter whether you
run a server or a desktop, keeping in mind what you stick on your
computer can cause grief if mishandled, or inappropriate versions or
whatever, can help prevent you becoming an ecological terrorist ;)

rachel

--
Rachel Polanskis                 Kingswood, Greater Western Sydney, Australia 
grove@zeta.org.au                http://www.zeta.org.au/~grove/grove.html
r.polanskis@nepean.uws.edu.au    http://www.nepean.uws.edu.au/ccd/
 "Yow!  Am I having fun yet?!" - John Howard^H^H^H^H^H^H^H^H Zippy the Pinhead