William McIlroy said:
because they reduce complaints. Shims are a bad thing because they can
open
security holes.
Umm ... so, you want we should take the shims out? Reduce the
compatibility??
One man's "undocumented feature" is another man's hours of
experimentation to discover how something really behaves and subsequent
relying on hard-won learned system behavior staying the same over
successive
OS releases. Why the experimentation? Because documentation is treated
as a
second-class citizen. It only hints at what programmers need to know. It
is
in no way a mathematically rigorous contract between Microsoft and
programmers. This probably is because writing documentation is difficult,
never done, and the underlying facts are always changing.
Well, I don't want to actually *defend* Microsoft's documentation, because I
spend a good slice of every working day swearing and cursing at MSDN, etc.
But to date, I haven't seen too many vendors providing "mathematically
rigorous" documentation of their APIs. Not IBM with CICS or MVS, not Oracle
with OCI, not Sun with Java, not BEA with WebLogic ... I could go on. I
understand what you want; and hell, I've even programmed in Eiffel (which I
greatly respect as a language, btw). But those kinds of contracts rarely
exist for non-trivial or non-hugely-expensive systems. It's an ongoing
problem in software engineering, and no vendor has solved it yet. Just read
any issue of the IEEE Transactions on Software Engineering, to see why this
is not yet a solved problem. Sometimes IBM is marginally better than
Microsoft at documenting stuff; other times, Microsoft has marginally better
docs than IBM. Often they both have better docs than Oracle, and none are as
good as the Java docs. But these are all minor variations on a theme; no
vendor is significantly, qualitatively better than any other vendor, in this
regard.
However, you can be pretty sure of a few things:
- if a feature, API or structure is undocumented, you use it at risk. There
is *no* guarantee it will be preserved in future versions.
- if a feature, API or structure is documented,. there is a very high degree
of probability that it will be preserved in version upgrades, *or* there
will be a clear indication that it has been deprecated or withdrawn, *or* it
will fail gracefully not violently.
Whatever other merits of the DoJ's action against Microsoft, MSDN is now
subject to legal scrutiny, as Microsoft's *legally binding* agreement of how
its APIs will behave. I believe, from informal discussions with Microsoft
developers, that they take documenting APIs very seriously indeed. Not with
mathematical rigour, certainly; it's still a human and fallible task - but
for example, if something appears in MSDN which is wrong or wasn't meant to
be there, the Microsoft guys then have to go and actually implement that
feature; in case an ISV has already used it; they can't just cross it out.
And so on.
I'd be very confident the reason the Cool Edit app is crashing is *not*
related to any kind of change Microsoft has made to a published API. More
likely, the ISV has done as you suggest, and grovelled in some undocumented
structure or API. "Ah-ha, this DISKIO_CONTEXT ScopeIndex is just the field I
need!" they cried, and then they use it in their code. But if ScopeIndex is
undocumented, and silently dropped in the next release of Windows (silently,
because it was never documented to begin with) then when running on on
Vista, the ISV's code tries to read from ... a non-existent field! Pulling
in a NULL is a distinct possibility. In fact, I can almost guarantee that no
deliberate change to an API will result in a successful null reference being
returned. It just wouldn't happen. Not even a crappy first-year programmer
would do that (well, maybe a crappy first year programmer ... but not
Windows devs).
As I say, I don't wish to defend or gild Microsoft too much, because (a) I
myself, as a porgrammer, wrestle with their documentation, and have pulled
out what little grey hair I have left, trying to get things working; and (b)
I have seen many, many Windows bugs over the years, were something does
indeed pass an inappropriate null pointer, or similar weird defect, and it
has been a genuine, died-in-the-wool, no-questions-asked BUG in Windows.
But - is the crash in Cool Edit caused by a lack of compatibility in Vista?
I seriously doubt it.
BTW, see here for a few funny stories from Raymond Chen about "undocumented
features":
http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/09/01/459023.aspx
http://blogs.msdn.com/oldnewthing/archive/2006/03/07/545295.aspx
His book has ~400 pages of such stories!
Fortunately, in my
case, the program in question does not fail often enough to be a serious
challenge. Still, when it crashes, it is disappointing.
Well, if Visual Studio catches the exception, you should be able to debug it
(I'm making the possibly presumptuous presumption that if you have Visual
Studio installed and you care about API documentation, you also know how to
write and debug programs). First, make sure your symbol path is correct:
http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx
then reproduce the problem. Walk back along the stack, looking for the place
where the null pointer came in as a parameter. Then look up that function's
doco in MSDN, and see what changes (if any) were described, for Vista. In
fact you'll probably find that no changes are described; and/or that the
null pointer comes from a ISV-defined function which grovelled in
undocumented spaces.
However, I do accept that you have an app which ran fine on XP, and no
longer runs okay on Vista. I've owned several apps lilke that myself. And,
yeah: it is frustrating. But it's probably wrong to blame Vista, per se.
Regards,
