Why is the function SHStripMneumonic misspelled?
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
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.
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 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.)
1. to get people away from a bad practice;
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.
Public API contracts are NEVER intentionally broken.
No they don't, unless you're somehow running Windows 10 on a 32 bit machine.
Been bitten a few times by programs bundled using ancient 16-bit InstallShield. It _does not_ work on Windows 10.
32-bit Windows still exists.
They're essentially a 486 core with some Pentium instructions added.
[1] http://ark.intel.com/products/55663/Intel-Atom-Processor-Z67...
Both have 64-bit capable Atom CPUs, but were deliberately shipped with a 32-bit userland (presumably to save on disk space).
Windows 10 running in 32-bit on 64-bit processors manages this without issue, so it can't be the hardware
the real reason is they couldn't be bothered to work around some of the technical issues: https://msdn.microsoft.com/en-us/library/aa384249.aspx
The explanation made no sense to me.
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.
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?
It's a different type of aggression than e.g. Linus or Theo, whom one can often find themselves agreeing with.
https://linux.die.net/man/3/creat
It goes way back to the murky beginnings of Unix.
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."
But I do wish they had used one abbreviation for control rather than two - fcntl vs ioctl.
Naming is hard.
"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."
https://blogs.msdn.microsoft.com/oldnewthing/20100804-00/?p=...
https://blogs.msdn.microsoft.com/oldnewthing/20161104-00/?p=...
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.
So, I wonder now, what are the exact criteria according to which MS documented APIs? Why would they want to keep these criteria secret?
The rest of the world doesn't seem to have such a hard time with these sounds.
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.
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".
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".
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.
I know that is highly unscientific, and probably doesn't reflect current linguistics, but it still makes sense to me :-)
1. it only applies to English,
2. aeiou are the five classical vowels of the Latin alphabet, but English has more than five vowels (see the table here: https://en.wikipedia.org/wiki/Help:IPA_for_English)
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.)
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.
I found some answers about exactly when US and UK English differ on this point, though none of them is comprehensive: https://english.stackexchange.com/questions/9192/cancelled-o...
I thought all of Microsoft's code was in one giant repo anyway, so it would literally just be 1 commit to update this.