Glass houses are great places to throw stones
Whenever I write an article explaining that programs should avoid doing X, I can confidently rely on a comment saying, “Well, Microsoft Product Q does this!” as if to say, “Gotcha, you hypocrite!”
But they’re saying “gotcha” to the wrong person. Because, and I’m sure it’s a shock to many people to read this, I did not personally write every line of software Microsoft ever produced. (And even if I did write it, I may have written it as a younger developer, before I learned about said rule. Because, and I’m sure this is also a shock to many people, I was once a beginner, too.)
If you find a Microsoft product breaking a rule, then go complain to that product team. Complaining to me won’t accomplish anything. I don’t have access to their source code, and even if I did, I certainly don’t have permission to go in and make changes to their code, nor do I have the time to go in and learn how their product works and figure out the right place to make the fix. Furthermore, and I don’t know if you all can handle three shocking revelations in one article, product teams do not send me every line of code for review.
Indeed, one of the reasons I write here about things programs should or shouldn’t do is because I myself will see a Microsoft product breaking a rule! By discussing the problem here rather than in an internal mailing list, the information gets out to everybody. And maybe, just maybe, the product team will read the entry and say, “Oops, I think we do that.” Because (shocking revelation number four) not all Microsoft programmers are seasoned experts in Win32 user-interface programming.
(Articles where I was consciously tapping my colleagues on the head include my discussion of
CallMsgFilter, the long and sad story of the Shell Folders key, and reminding you to pass unhandled messages to
DefWindowProc. In fact, for every “do/don’t do this” article, I’d say odds are good that with enough searching, you can find a Microsoft product that breaks the rule. And when you do, complain to that product team. Even the difference between the tray and the notification area was in part a response to all the other groups that perpetuate the misuse of the terminology.)
So when I write something like, “Applications shouldn’t do this”, go ahead and insert the phrase “and this means all applications, including those published by Microsoft.” When I write, “some annoying programs”, go ahead and insert the phrase, “which might even include programs published by Microsoft”. I’m not going to insert those phrases into every sentence I write. I’m assuming you’re smart enough to realize that general statements apply to everyone regardless of who signs their paychecks.
Of course, if the consensus of my readership is that I shouldn’t tell you not to do things until every last Microsoft product has been scoured to ensure that none of them violate that rule either, then I can abide by that decision. I’ll just stop posting those tips here and keep them on the internal mailing lists. It’s much less work for me.