TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date: Tue, 18 Jul 2000 12:49:28 -0500
Reply-To: Randy Brukardt <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <01BFF0B1.AEAB4200@IGNITOR>
Content-Type: text/plain; charset="iso-8859-1"
From: Randy Brukardt <[log in to unmask]>
Parts/Attachments: text/plain (65 lines)
> Tom Moran[SMTP:[log in to unmask]] sez:
>
> > >"STANDARDS.
> > >
> > >Clearly defined and agreed-upon conventions for programming
> > >intefaces. Standards may be (bullets mine)
> >
> >   Can someone please point me to the clearly defined standards for the
> > Windows API?
> >
> You'll also find it in the Platform SDK HTML help files,
> e.g., win32.chm and shelcc.chm (to pick two of the more
> useful ones).  And Petzold's book (which is published by
> Microsoft Press).

Calling Petzold's book part of a standard is about the same as calling John
Barnes' book as part of the Ada standard.

> If you're intending to claim that Microsoft doesn't document
> their API thoroughly, I think you'll find a lot of skepticism.

You've apparently never tried to use their documentation to build something
substantial. Our experience building Claw is that the SDK documentation is
full of errors and (especially) omissions. You simply cannot build working
code by reading that material: you still have to write and test code on
every platform that you intend to support.

To take one example, the SDK documentation never says which styles can be
modified after a control is created. (Petzold often uses this technique in
his examples). But many have an effect only when a control is created. A few
are documented that way, but many more are like that. The only way to find
out for sure is to try changing them and see what happens. Moreover, the
results are sometimes different on different versions of Windows (i.e. 98,
NT, etc.). [That at least shows that Microsoft isn't hiding any *good*
documentation -- they really don't know how these things should behave -- so
their development teams end up with different behavior.]

So to claim that the SDK documentation is "clearly defined" is myopia at
best. It's useful stuff, but it doesn't come close to the rigor necessary in
a standard.

> Mind you, I have 2 or 3 books open on the desk and 2 or
> 3 windows open on my computer whenever I do something
> I haven't done before in Windows -- they aren't the greatest
> at organizing their documents, but it's all there if you can
> figure out where to find it.

And I bet that you have to use a voting algorithm to figure out how to
proceed, as at least one of them will be wrong almost all of the time.

Of course the Windows API is a "de-facto" standard. But to claim that there
is any real definition of that standard besides the implementations
themselves is simply untrue. (And, yes, I believed otherwise until I got
into trouble repeatedly by believing the SDK docs. But the books Tom had
were worse...)

                        Randy.

P.S. Welcome to the thread that won't die. :-)

Memo to Rick: I've read this whole thread, and I think that most of the
E-Mail supports Mike Feldman's possible. I don't know what mail you read,
but you'd have to twist it a lot to support your position. Perhaps Microsoft
has figured out a way to brainwash attendees to Tech-Ed? :-)

ATOM RSS1 RSS2