That is exactly what I thought. I get that when it's public that is harder, but still not impossible. Software is practically never "set and forget", when those times when it is, you won't be affected either since you often don't upgrade the runtime or OS either (which is it's own can of worms).
Scrolling through logs on Linux and macOS shows a few 'deprecated' warnings here and there, and looking those up show that on average they have a few major release lifespans, and sometimes never even get removed because there is no cost to keeping it and no benefit to removing it. Often, programs have a fix in whatever update comes next and the owner often fixes those deprecation issues as a side-effect.
It's strange that Microsoft is so very good at constantly shooting themselves in the foot with this type of never ending backwards compatibility. (that often turns out to be not-so-compatible after all)
The trouble with Windows comes down to new installations of old software on new operating systems. You can't deprecate anything, because some 20-year-old binary might schlep its way onto a customer's Windows 10 box, and they'll expect it to work.
(The real key to fixing this would be layers of frozen-in-time compatibility sandboxes, allowing code written in 1995 to get a 1995-era synthetic environment, while the frameworks of today can forget about 1995. But that means dropping the ability to fix security flaws in any of that old code; or extend it with accessibility-device support that didn't exist back then; etc. The choice is obvious, and yet extremely unpalatable as well.)
You can still mark it deprecated, even if you don't actually get around to removing it - code that gets recompiled will see the warning and hopefully fix it, and that which doesn't will still work.
2. to enable rearchitecture or refactoring that can't take place with a function of the old style "in the way"; and
3. to reduce maintenance burden.
Indefinite deprecation without removal helps with #1, but doesn't aid either #2 and #3—and without those additional benefits, usually there's no point: if you're going to be maintaining the function in perpetuity anyway, and won't be able to change the framework out from under the function, then people may as well keep using the function.
Keep in mind, also, that "deprecation" can't do much to control Windows developers; they make full and willing use of even private APIs, raw writes to private registry keys, etc. whenever they find them. Microsoft tries to keep compatibility even with these programs. With such developers around, deprecating a feature doesn't change much; as long as it's there, and calling it works, people will continue shipping code that calls it despite the warnings. They'll even write new code that calls it.
And a third argument: sometimes Microsoft deprecates a particular API for accessing some functionality, and doesn't go on to provide any alternative API for that functionality. And this isn't a case where they're saying "you just shouldn't be trying to do that any more"; these are cases where there is MSDN documentation that tells you how to idiomatically do something... by using a deprecated function. This taints the "reliability" of deprecation as a useful signal for Windows developers.
Those three effects together mean that Microsoft mostly just doesn't bother. Instead of trying to evolve APIs at all by deprecating old features and then refactoring the API surface once the old functions are "out of the way", Microsoft simply write entirely new APIs, leaving the old APIs in place. The old DLL is still there, and still maintained. It might sometimes have been hollowed out into a shim wrapper that calls into the new API... but it's very unlikely, because that destroys "bug for bug" compatibility.
Microsoft has very well handled backward compatibility in Windows 95, but very badly with Windows Vista. IMHO, this was a very hard to fix mistake that Microsoft is still paying.
One of the central reasons for Windows's success is backwards compatibility. 16-bit Windows 3.1 applications still work in Windows 10. There are countless teams at Microsoft whose sole purpose is to verify backwards compatibility with almost every piece of software that more than a handful of people are running.
Public API contracts are NEVER intentionally broken.
Not only does it still exist, devices running 32-bit Windows 10 are still actively sold. I purchased one in 2016 (Intel compute stick) and another in 2017 (Ollee D1016W).
Both have 64-bit capable Atom CPUs, but were deliberately shipped with a 32-bit userland (presumably to save on disk space).
While technically correct sth. like the Quark is probably not what he meant but some earlier models of the Atom lineup (<= 10y, 2008 onwards) are 32bit chips. There are chips released as late as 2011 [1] which lack 64 bit support.
^ this, and later on removing it from the header files so nobody can accidentally use it (e.g. reading old documentation), but existing software can still call it.
The article makes it clear that the problem with renaming was not that it would break backward compatibility (because it was still a private API when this was considered) but that it would be painful to coordinate all the teams to make the change simultaneously.
Okay so the ultimate cause is apparently "because Microsoft was legally compelled to publicly document poorly-designed internal functions as part of the DOJ anti-trust suit".
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.
It's annoying, but given that it's nearly a decade old it's probably not worth getting upset over it.
Well, I was wondering if there's some "wink wink, know what I mean" thing going on when he repeated the original non-explanation verbatim, underlined and bolded.
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.
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.
That's in addition to a lot of aggressive or condescending answers I've read to what seem quite reasonable questions.
If commenters are such a problem, wouldn't it by now be better to simply close comments completely?
I don't follow his blog but it does turn up in searches, which is how I usually read his posts, and that was enough to see the same sort of attitude you allude to. He seems to really enjoy gloating over the fact that he knows some things about Windows but others don't.
It's a different type of aggression than e.g. Linus or Theo, whom one can often find themselves agreeing with.
That's not quite the same thing as it's not so much a misspelling as a result of being restricted to five chars. (on some certain system the details of which doesn't interest me)
But I do wish they had used one abbreviation for control rather than two - fcntl vs ioctl.
For anyone wanting to see the linked IOCCC program (now-broken link in the third paragraph), here it is: http://ioccc.org/1987/hines/hines.c
"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.
Whenever Raymond does that, I want to know more, just out of spite. He once banned discussion of a internal DWM api, I think one that made transparent windows tinted, and I learned a great deal trying to figure out what he was hiding.
So, I wonder now, what are the exact criteria according to which MS documented APIs? Why would they want to keep these criteria secret?
It now says that "First-time commenters will be moderated." BTW. The feature the 2016 blog post talked about was invented in 2011 or so as part of Win8 BTW.
If it made it into a public Windows release, and is useful (well clearly it's useful, since multiple internal teams called it), the deprecation cycle is measured in decades. It's not worth deprecating something because it was poorly spelled, when there are lots of other things to deprecate for good reasons.
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.
I also pronounce it without an "u" sound. I'm never sure what to do with the "mn", though. For all I know, it is impossible to pronounce two consonants in that way, you'll have to add a (implicit) vowel.
Do people say "nemonic", or "me-nemonic" or "em-nemonic"? If I really try to avoid an implicit vowel, I could say "hmmm-nemonic", but that sounds weird, and there is still a vowel in there.
I once heard the suggestion to join the "impossible" consonant to the previous word, so "the mnemonic" would be "them nemonic". It came up with "chtonic" and "chtulu" (the chtonic gods = "theχ tonic gods" / "thek tonic gods"). I like that idea, although it seems highly nonstandard.
As I understand it, the initial m is silent, so no 'implicit vowel' is required, the 'mn' is pronounced like 'n', e.g. 'new-mon-ik'. The other word you mention (actually spelled 'chthonic') is pronounced with the initiall 'k' or 'ch' sound, like 'k-thonic'. If you search Google for the words, or look on Wiktionary, there should be a handy audio link with examples.
Where is the vowel between m and n in "hmmm-nemonic"? If you put your tongue tip up before you open your mouth (or even while you do it), the airflow is restricted throughout the whole transition.
If the consonants in the cluster are unvoiced, it is even easier to avoid an implicit vowel by simply not voicing anything and pronouncing the individual consonants in fast succession, just like "ch" is formed from "t" and "sh".
What I wrote as `h` functions as a vowel here. Is is by definition impossible to have a consonant without a vowel. When you say "mmm", it is really "ummm" or "emmm". Even if you just humm to make the m, you'll have an initial sound at the beginning.
I think of it a bit like fourier analysis. Like you automatically have higher frequency components when you have a rectangular wave form. Turning on the "m" out of nothing looks or sounds like an "e". I think you could make a recording of "mmmm", cut of the beginning or the end, and the transition from/to silence would still constitute a vowel.
You can choose to have the vowel before, or after the m. Most often I've heard "m(e)nemonic".
> Is is by definition impossible to have a consonant without a vowel.
I'm not sure what definition of vowel you subscribe to, but I tend to mean "a sound pronounced with an open vocal tract" [1], in which case you can have consonants without vowels. In particular, a simple transition from silence to voice does not constitute a vowel (nor does it sound very much like one, in my opinion).
I also don't understand how you could choose to have the vowel before or after the m; under your definition of vowel, it would seem like every "mmm" would have to be "(e)mmm(e)" instead.
Just what I learned in elementary school (1st grade in the US). Vowels are the five letters of the english alphabet that are special, because the pronunciations of all other letters contain a vowel. That's why the others are called consonants (with-sounders).
I know that is highly unscientific, and probably doesn't reflect current linguistics, but it still makes sense to me :-)
3. although in English every consonant occurs in a syllable together with a vowel (as a with-sounder, if you will), there can be multiple consonants in one syllable. E.g. "claps" is a single syllable with one vowel "a" and four consonants. There is no vowel directly adjacent to "c" or "s". This is also the case for "mnemonic": the syllable "mne" has one vowel and two consonants. (Except in the English pronunciation, where the "m" is dropped.)
It's not that hard to glide from the /m/ to the /n/ without an intervening vowel or anything before the /m/, it is just unfamiliar to anglophones. The Russian language has all kinds of bizzare consonant combinations, and they manage to make it work.
Also note that the "p" is always silent, because the English language hates hard-to-pronounce sounds such as those generated by putting two nasal consonants next to each other. Same for "s-y-chosis", "s-eudo", ...
The rest of the world doesn't seem to have such a hard time with these sounds.
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 only if you pair it with a plan for making the old one go away forever (a plan that you stick to!).
If you aren't serious about actually removing a bad API at some point, don't change anything. Otherwise, you create two things that need to be tested/supported/kept binary-compatible/etc. instead of one, raising technical debt when you were supposed to lower it.
Interesting, "referer" always looked believable to me as an alternative spelling from American English, by analogy with the likes of "traveler". But apparently not, because the accent is on the syllable that would be changed.
> 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.
I thought all of Microsoft's code was in one giant repo anyway, so it would literally just be 1 commit to update this.
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?
Mark the bad function deprecated, warn the teams and after a few release cycles, remove it.