6 ms·

> so there would have to be some coordination among the teams so everybody fixed their spelling at the same time. What a strange approach. Why not create a fun

> so there would have to be some coordination among the teams so everybody fixed their spelling at the same time. 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.

oneplane 9y ago
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)
- derefr 9y ago
  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.)
  - zachrose 9y ago
    Still though, having a correctly spelled version and and incorrectly spelled version sounds better than just the latter.
  - sbmassey 9y ago
    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.
    - derefr 9y ago
      Deprecation can serve three purposes: 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.
- reacweb 9y ago
  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.
  - Neliquat 9y ago
    You must not remember 95. I spent days trying to get my 3.1 games and dos games to run. Still had to boot to DOS often. 95 was both a breakthrough, and a trainwreck.
marcoperaza 9y ago
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.
- TylerE 9y ago
  > 16-bit Windows 3.1 applications still work in Windows 10 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.
  - TazeTSchnitzel 9y ago
    “Somehow”? 32-bit Windows still exists.
    - TylerE 9y ago
      Intel hasn't sold a 32bit chip in over 10 years.
      - TazeTSchnitzel 9y ago
        Yes, but machines with 64-bit CPUs are still being sold with 32-bit OSes for various reasons.
        saurik 9y ago
        One reason being "to run my old 32-bit software".
        marcoperaza 9y ago
        You are mistaken. 32 bit software runs flawlessly on 64 bit Windows.
xxs 9y ago
That's pretty much a standard procedure: Deprecate "in favor of", i.e. the correctly spelled one. You get compiler a warning telling you to rename it. The explanation made no sense to me.

oneplane 9y ago

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)

derefr 9y ago
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.)
- zachrose 9y ago
  Still though, having a correctly spelled version and and incorrectly spelled version sounds better than just the latter.
- sbmassey 9y ago
  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.
  - derefr 9y ago
    Deprecation can serve three purposes: 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.
reacweb 9y ago
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.
- Neliquat 9y ago
  You must not remember 95. I spent days trying to get my 3.1 games and dos games to run. Still had to boot to DOS often. 95 was both a breakthrough, and a trainwreck.

marcoperaza 9y ago

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.

TylerE 9y ago
> 16-bit Windows 3.1 applications still work in Windows 10 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.
- TazeTSchnitzel 9y ago
  “Somehow”? 32-bit Windows still exists.
  - TylerE 9y ago
    Intel hasn't sold a 32bit chip in over 10 years.
    - TazeTSchnitzel 9y ago
      Yes, but machines with 64-bit CPUs are still being sold with 32-bit OSes for various reasons.
      - saurik 9y ago
        One reason being "to run my old 32-bit software".
        marcoperaza 9y ago
        You are mistaken. 32 bit software runs flawlessly on 64 bit Windows.

xxs 9y ago

That's pretty much a standard procedure: Deprecate "in favor of", i.e. the correctly spelled one. You get compiler a warning telling you to rename it. The explanation made no sense to me.