Holy cow, I wrote a book!
Three examples off the top of my head of the consequences of
grovelling into and relying on undocumented structures.
Of course there was no mention of this illicit behavior in the documentation.
So when the background defragmenter corrupted their disks,
Microsoft got the blame.
From the shell extension, they used an undocumented window message
to get a pointer to one of the internal Explorer structures.
Then they walked the structure until they found something they
recognized. Then they knew, "The thing immediately after the thing
that I recognize is the thing that I want."
Well, the thing that they recognize and the thing that they want
happened to be base classes of a multiply-derived class. If you
have a class with multiple base classes, there is no guarantee from
the compiler which order the base classes will be ordered.
It so happened that they appeared in the order X,Y,Z in all the versions
of Windows this software company tested against.
Except Windows 2000.
In Windows 2000, the compiler decided that the order should be X,Z,Y.
So now they grovelled in, saw the "X" and said "Aha, the next thing must
be a Y" but instead they got a Z. And then they crashed your system
some time later.
So I had to create a "fake X,Y" so when the program went looking for
X (so it could grab Y), it found the fake one first.
This took the good part of a week to figure out.
It so happens that the NMHDR is allocated on the stack, so this
program is reaching up into the stack and grabbing the value of
some local variable (which happens to be two frames up
the stack!) and using it to control their logic.
For Windows 2000, we upgraded the compiler to a version which
did a better job of reordering and re-using local variables,
and now the program couldn't find the local variable it
wanted and stopped working.
I got tagged to investigate and fix this. I had to create
a special NMHDR structure that "looked like" the stack
the program wanted to see and pass that special "fake stack".
I think this one took me two days to figure out.
I hope you understand why I tend to go ballistic when people recommend
relying on undocumented behavior.
These weren't hobbyists in their garage seeing what they could do.
These were major companies writing commercial software.
When you upgrade to the next version of Windows and you experience
(a) disk corruption, (b) sporadic Explore crashes, or
(c) sporadic loss of functionality in your favorite program,
do you blame the program or do you blame Windows?
If you say, "I blame the program," the first problem is of course
figuring out which program. In cases (a) and (b), the
offending program isn't obvious.