R> From: "Rich" 

 R> This is a multi-part message in MIME format.

 R> ------=_NextPart_000_0272_01C2A6DF.5614B270
 R> Content-Type: text/plain;
 R>         charset="iso-8859-1"
 R> Content-Transfer-Encoding: quoted-printable

uuuggghhh...

 R>    Windows can have any number of versions.  Always could.

oh? how can i have different versions of CTL32.DLL in the \windows\system
directory? this is one very common example... there are others but i can't
think of them at the moment...

 R> So can every system with which I'm familiar that supports
 R> shared libraries. It's irrelevant.  The problems occur either
 R> when a shared library producer believes he has provided a
 R> compatible upgrade and wants existing clients = to use it or
 R> when a client of a shared library misuses the library and
 R> either intentionally or unintentionally relies on undefined
 R> behavior and there is a change in the undefined behavior.
 R> The latter is very common.

agreed... but windows doesn't enforce keeping its system dlls clean and
clear from outside "upgrades" or "enhancement"... this
new stuff in XP called "system file protection" isn't... it is
"system file replacement" as someone else recently pointed out...
and, as Geo pointed out, it doesn't prevent anyone from putting a bogus
file of the same name earlier in the search path... and none of this
enforces making the programers code to look in a specific (set of) place(s)
for dlls they need... we won't even talk about installer programs that
overwrite files without checking versioning information or even things that
m$ is also guilty of like not properly updating the versioning information
or even storing that versioning information in a place properly set aside
for it...

 R>    One of my favorites of the latter is the example of an
 R> application that had an uninitialized stack variable.  It
 R> just so happened that an API called just before the call
 R> to the function with the uninitialized value just so
 R> happened to have the uninitialized location assigned to a
 R> local that would always be set to zero before the API
 R> returned.  This had the side effect of the leaving a
 R> reasonable value in the uninitialized location.  When the
 R> API changed so that its stack layout changed the buggy
 R> application started to fail.

yes, i've seen this in many coding situations... its one of the reasons why
i like pascal and other similar languages so much... especially when the
enforce the defining of variables and go so far as to warn about them not
being initialized...

)\/(ark