Feel free to delete this if you're bored with the thread.

Randy Brukardt sez:

> > >> 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.
I really do think there's a difference, and Petzold's book has
a quasi-official status that Barnes's book doesn't have.  If he
were an employee of AdaCore and the book were published
by AdaCore Press, then your analogy might be correct.


> 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).
I've got a little toy at home that creates and modifies windows
with the various flag bits.  I'll see if I can dig it up.  Damn useful.
And of course there's the control spy toys.

Have you run into the thing where controls defined in the RC
file don't work right and you have to define them in the C code?

> 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.).
Actually, it's the DLLs, at least wrt non-MFC controls.  And new
DLL versions are produced at the behest of various groups in
Microsoft, particularly the MSIE group, who have been responsible
for two major releases each of the Big Two (for us non-MFC
guys): comctl32 and comdlg32.

However, Microsoft, to its credit, is scrupulously clear about what
versions a given option is good for.  If you want checkboxes in
your listview controls, you're gonna have to make your customers
install MSIE 5 or draw them and manage the mouse click yourself.

> [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.]
Naah, it's just evidence that the folks who wrote the old version are
gone, except for a couple of managers.  These managers and the
managers who are working on the current version hate each other
and haven't spoken in years.

> 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.
I've had a chance to study quite a few standards in recent years,
and even contribute in a small way to a couple, and I can't think
of one that even comes close to the rigor of the Ada standards.
There's way too much "then you wave your hands and the magic
happens" and neglect of initial and final conditions.  About the
only truly outstanding thing I've seen in a spec recently is the
ECMA-262 math function definitions.

So I think your operational definitions of "standard" and "clearly
defined" are set too high for real-world standards.