Another War Story

[Steve Cohen <stevecoh@mcs.com>]

We had a little trouble at work today.  Our product uses a few
third-party ActiveX controls, but most of our code was written either by
us or by outside consultants.  (I am using the term "ActiveX" in its
generic sense here which means the same thing as "OLE controls".  This
has nothing to do with the Internet.)  My employer was against using
Third Party controls but the outside consulant slipped in a couple and
we're semi-stuck with them.  This year we added a few more.  Anyway, for
a variety of reasons, we decided to "get legal" and buy one licensed
copy of these controls per developer at 300 bucks a pop.  And there lies
a tale:

The controls we bought were a different version than the one we
previously used.  Not a major version upgrade, 2.0 to 2.1.  However, we
found that once the 2.1 controls were installed, last year's version of
our products, which used version 2.0 would not run properly.  The
controls were not binary compatible but both bore the same GUID
(globally unique identifier).  That's the same magic cookie which
Windows stores in the registry and which is supposed to uniquely
identify the ActiveX control.

This posed some interesting problems.  What if some of our users decided
to use the 1998 version of our product A and the 1999 version of our
product B.  They're screwed.  If they install 1999B 1998A won't run.
What if we didn't upgrade, but some other software company that used
these Third Party controls did, and our users bought their product.  Now
we and they are both screwed.  Our product won'r run, a tech support
nightmare.

This isn't supposed to happen.  Rule 1 of OLE was supposed to be that if
you change the interface you can't use the same GUID - you've created a
new interface and should not expose your users to this sort of hazard.
That's apparently out the Window.

We talked to their tech guys on the phone.   Their suggestion was to
dynamically register the control at program startup!  LOVELY.  I suppose
we could restore the system to its previous state on exit but 1) That
means the two programs that use conflicting versions of the control
can't run simultaneously.   And 2) What if we crash?  So now this is
being dealt with on the executive level.  Lawsuits may not be entirely
out of the question.

This vendor is one of the industry leaders in this field.  If you read
PC programming magazines you'd recognize their name.  To some degree
they're in tight with Microsoft, but they did make some oblique comments
to the effect that Microsoft somehow was forcing them to do this.  It
doesn't make sense to me, but I put nothing past Microsoft, either.
Still, I tend to believe that this was a massive screwup by the vendor
and not directly Microsoft's fault since I don't understand why they
couldn't have changed the GUID.

Still, it shines a Klieg light on the fragility of Windows.  Everyone's
sharing "components", all able to be "plugged in" at the touch of a
mouse, with no reliable system of keeping it all running smoothly,
without vendor A breaking vendor B's products.  As the leader of this
mess, Microsoft should be reading this company the riot act - except
they of course have no moral standing to do so, since that's exactly
what they do all the time.

The emperor is truly unclothed.