> so there would have to be some coordination among the teams so everybody fixed their spelling at the same time.<p>What a strange approach. Why not create a function with the correct name, put the code in it and redirect the misspelled function to it?<p>Mark the bad function deprecated, warn the teams and after a few release cycles, remove it.
Okay so the ultimate cause is apparently "because Microsoft was <i>legally</i> compelled to publicly document poorly-designed internal functions as part of the DOJ anti-trust suit".<p>Go figure why Raymond Chen decided to do a blog post on this though, since apparently that is a verboten topic which leads to a weirdly sparse article that doesn't answer its title question, and a censored comment thread.<p>It's annoying, but given that it's nearly a decade old it's probably not worth getting upset over it.
Raymond Chen's blog post are always interesting and enlightening to read and we should be grateful that he takes the time and effort to write them - but his people skills appatently could use a good bit of improvement.<p>So he teases a significant detail of the answer, then notes that not only won't he explain but he will not allow anyone else to explain either - no reason given. Then, when people unsurprisingly do discuss it, he gets mad and deletes the comments.<p>That's in addition to a lot of aggressive or condescending answers I've read to what seem quite reasonable questions.<p>If commenters are such a problem, wouldn't it by now be better to simply close comments completely?
See also: creat()<p><a href="https://linux.die.net/man/3/creat" rel="nofollow">https://linux.die.net/man/3/creat</a><p>It goes way back to the murky beginnings of Unix.<p>Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e."
For anyone wanting to see the linked IOCCC program (now-broken link in the third paragraph), here it is: <a href="http://ioccc.org/1987/hines/hines.c" rel="nofollow">http://ioccc.org/1987/hines/hines.c</a><p>"This program was designed to maximize the bother function for structured programmers. This program takes goto statements to their logical conclusion. The layout and choice of names are classic."
The order they are referring to is probably the DOJ settlement in 2002. There used to be a page called "Settlement Program Interfaces" in MSDN. This was also when winternl.h was invented.
I pronounce "mnemonic" without any "u" sound, and I've almost never heard otherwise, so this particular misspelling is a little puzzling --- unless the original author was thinking of "pneumonic". I wonder if it is a UK vs. US difference.
This story just teases that there will be an answer and then doesn't really give one. To paraphrase the ending: "We had to. To those writing in to explain that we didn't have to, trust me, we had to."
Deprecation is a really good solution for fixing things "eventually" but <i>only</i> if you pair it with a plan for making the old one go away forever (a plan <i>that you stick to</i>!).<p>If you aren't serious about <i>actually</i> removing a bad API at some point, don't change anything. Otherwise, you create <i>two</i> things that need to be tested/supported/kept binary-compatible/etc. instead of one, raising technical debt when you were supposed to lower it.
For the same reason the Referer header is misspelled in HTTP - because life can sometimes be that way.<p><a href="https://en.m.wikipedia.org/wiki/HTTP_referer" rel="nofollow">https://en.m.wikipedia.org/wiki/HTTP_referer</a>
The correct link to the IOCCC entry is:<p><a href="http://www0.us.ioccc.org/1987/hines/hines.c" rel="nofollow">http://www0.us.ioccc.org/1987/hines/hines.c</a>
> The effort required to fix the spelling was a bit more than usual, since the function was used by multiple teams, so there would have to be some coordination among the teams so everybody fixed their spelling at the same time.<p>I thought all of Microsoft's code was in one giant repo anyway, so it would literally just be 1 commit to update this.