The Wild, Wild West - Undocumented APIs

Larry Osterman and Raymond Chen are constantly pointing out that third party developers use undocumented APIs and implementation side effects of the Windows APIs, and other OS internal details.  A common refrain among developers is that such things shouldn't be done, and Microsoft shouldn't be afraid to 'break' applications that dare to use undocumented features.

Unfortunately, I think that we are looking at the past through 'revisionist history'.  If I hit F1 in VS.NET today, or go to msdn.microsoft.com, I can easily find information on just about anything I want to do.  If MSDN is insufficient, I can hit Google, and I'm all set.  There are plenty of books lining the local Barnes & Noble, and I can always ping people like Yang Cao, or Paul Wilson if I need an answer.

But that's not how things have always been.  Back in the '90s, programming against windows wasn't so easy.  There was no google.  Microsoft API documentation was anemic, and often incorrect.  It was common for a programmer to have to figure out how an API worked through trial and error, and a bit of debugging.  On top of this, it was common for other Microsoft applications to use undocumented APIs, or use documented APIs in undocumented ways.  In fact, one analysis points out that Microsoft still does this.

Microsoft isn't the only party guilty of poor documentation - I've been on several software teams that have produced reams of useless docs, while still not addressing core user needs. I'm not picking on Microsoft documention, but I am pointing out that some things need to be put in historical context.