Long post. Sorry, best I could do. Contents:
THEORY
MY COMMENTS
ABCcheck
I was in the MS Windows development team and worked on various versions of
NT as well as 95 and 98. This is the way it works (or doesn't as the case
may be).
THEORY:
Application programs are never self-contained; they always depend on
facilities provided by the system in the form of Dynamic Link Libraries (aka
DLLs).
New versions of DLLs appear all the time. MS fixes bugs or might even slip
in some new thing that someone has been screaming for, or that just missed
the previous main release or whatever. The new versions come out via MSDN
or other routes and there are "silent" updates which means that MS just
alters the thing without any publicity (because the changes are not
news-worthy).
So if you develop a product and test it with (say) version 4.0.1381.6 of
iprop.dll and then a customer installs it on a system with version
4.0.1381.4 then it MIGHT be the case that an important fix that affects your
program came out between these two. So you ship with your product all the
DLLs that it might need and your Setup compares your version with the
version on the system and takes whichever is the later. If it copies in the
newly supplied one, it keeps a back-up copy of the old one. If you want to
back out the changes then you can run Version Conflict Manager (find it in
Start; Help; Index; Version and click on the link). It's also in Start;
Programs;Accessories; System Tools; System Information; Tools; Version
Conflict Manager. IT'S FOR EXPERTS ONLY - FEEL FREE TO *LOOK*, BUT DO NOT
MESS WITH IT!
MY COMMENTS:
There have been (rare) instances of applications creating their own enhanced
versions of particular DLLs and shipping them with their products. That is
foul play and it guarantees mayhem. There have been (rare) instances of
faulty installation where the new application copies its own DLL in
regardless of version number and so *downgrades* the system. There have
been (rare) cases of regression bugs in which the new version, while fixing
the things it was supposed to fix, introduces a bug somewhere else. There
have been (rare) cases of incompatibilities where some combination of DLL
versions doesn't work as it's not possible to test all combinations of
versions (there are best part of a thousand DLLs, just 2 versions each of
just 10% of them would need over 1000000000000000000000000 tests). All
these rare things start to add up to not-so-rare.
Many people have noticed that if they take Windows it runs pretty reliably
at first, but over time seems to get more and more unreliable until in the
end you have to reinstall it. The above is one of the mechanisms of system
rot.
It gets worse if you try to back changes out. Some "Uninstall" programs are
Russian Roulette (and please do NOT mess with Version Conflict Manager).
For this reason my own personal opinion is that SHIPPING DLLs IS TO BE
AVOIDED. (Muse does not ship any). As an application developer, the
sensible thing to do is to play down the middle of the fairway and use only
system facilities that are heavily used by many programs and thus have been
tested to death (or maybe eternal life) and are going to work just fine in
every DLL version that you will ever encounter.
ABCcheck:
Microsoft believes (with some justification) that it's OK for MS apps to
ship new versions of MS DLLs with MS products. So if you install (say) MS
Office then you will likely get some system DLL upgrades with it. If you
are writing in VB (Visual Basic) then the program that your customers
actually run is the VB interpreter, which is an MS product. The question is
"do you need to ship the VB interpreter with ABCcheck?" If so, then you
probably do need to ship all those DLLs because you have no idea what the
interpreter might do. If not, then don't! If you can make it optional,
then please do.
Hope this helps
Laurie
------------------------------------
Synopsis of previous thread:
> I am uncomfortable with freeware that messes with /WINDOWS/SYSTEM.
> If possible offer a non-Setup version which can just "unzip and run".
I thought Setup was the standard approach.
> You include....
> COMCAT.DLL STDOLE2.TLB ASYCFILT.DLL OLEPRO32.DLL
> OLEAUT32.DLL MSVBVM60.DLL
>
> All these DLLs were already on my system.
> You should make it optional to download these DLLs.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
