4 ms·

Because Microsoft have long had a reputation (especially at the time) for maintaining compatibility over a very long period for applications. They did horrendou

by mathw 9y ago

Because Microsoft have long had a reputation (especially at the time) for maintaining compatibility over a very long period for applications. They did horrendous engineering to make DOS applications still work through Windows 95 and onwards because their customers still needed it. This was considered an important thing for the product. Windows is still one of the most backwards-compatible systems you're ever likely to encounter. Sure, not everything works anymore, but you can still install a lot of software written for Windows 95 and expect it to still function. That's hugely impressive, given that we're not even running the same kernel anymore.

mschuster91 9y ago
> That's hugely impressive, given that we're not even running the same kernel anymore. Unless you're doing shenanigans with ioctls to devices or direct access to kernel functions, the kernel does not really matter - everything goes through user32 and friends anyway, so as long as MS does a good job keeping this abstraction layer stable OS upgrades don't concern you much.
- danbruc 9y ago
  [...] as long as MS does a good job keeping this abstraction layer stable OS upgrades don't concern you much. The problem is that you have to keep them stable to a much higher degree than you might think at first. Obviously you have to maintain the functionality as described in the API documentation but that is far from enough. If the implementation has a bug, you can not simply fix it because there might be software either relying on the wrong behavior or having implemented workarounds that you might break with the fix. And no matter how often the API documentation states that this or that is not supported or undefined behavior there will be software doing it anyway or relying on what ever undefined behavior meant in the version they developed against. You return a list of something and say nothing about the ordering in the documentation but as an implementation detail it happens to be in some specific order, if you wait just long enough there will be a program critically depending on the ordering you choose. This is an endless nightmare especially if your APIs have as many different consumers as the Windows APIs.
- whoopdedo 9y ago
  Out in the wild though everything doesn't go through user32 and friends. Antivirus in particular is notorious for ignoring public APIs.
yesenadam 9y ago
>This was considered an important thing for the product. Backwards compatibility used to be the norm for most stuff, didn't it? In the 80s/90s. You didn't need to get a new computer every few years. Now if there's a problem, the solution is easy - "Buy a new computer/phone/iPad."
- dingo_bat 9y ago
  > Backwards compatibility used to be the norm for most stuff, didn't it? I think this seems true only because of Microsoft. I cannot recall any other major OS spending so much effort on backward compatibility.
  - cesarb 9y ago
    > I think this seems true only because of Microsoft. I cannot recall any other major OS spending so much effort on backward compatibility. The king of backward compatibility is probably IBM. AFAIK, their mainframe operating systems can run unchanged software from before MS-DOS was born.
    - wilsonnb 9y ago
      That's true. You can supposedly run a program assembled or compiled in the 60's on a z14 that you buy today. Seeing as most of IBM's largest customers are banks and other places that have no interest in rewriting battle tested software, it's probably the reason that their mainframe department is still alive.
  - beefhash 9y ago
    SCO OSes are also backwards compatible to hell and back.
- bpicolo 9y ago
  This is one place where the Web continues to reign supreme. Did we re-implement an OS on top of our OS? Sure. But it's been a tremendous success for accessibility.
Const-me 9y ago
Unfortunately, a lot of software written for Windows 95 comes with 16 bit installers. And there's no 16 bit compatibility in 64 bit Windows.
- cesarb 9y ago
  > And there's no 16 bit compatibility in 64 bit Windows. Since we're talking about the lengths Microsoft goes towards backwards compatibility: https://msdn.microsoft.com/en-us/library/aa384143(VS.85).aspx https://msdn.microsoft.com/en-us/library/aa384143(VS.85).asp... "For older applications that use a 16-bit stub to launch a 32-bit installation engine, 64-bit Windows recognizes specific 16-bit installer programs and substitutes a ported 32-bit version." (However, this is not always enough: https://davidcmoisan.wordpress.com/2010/02/18/16-bit-installer-support-in-windows-64/ https://davidcmoisan.wordpress.com/2010/02/18/16-bit-install...)
  - Const-me 9y ago
    > this is not always enough Right, I have one 1997 videogame that uses InstallShield 3.0.95.
- eumoria 9y ago
  Yea that was the big break in compatibility. There's also many applications that were written for the specific hardware and many undocumented features (hacks) on 95/98 that modern Windows cannot handle.

by mathw 9y ago

mschuster91 9y ago

> That's hugely impressive, given that we're not even running the same kernel anymore. Unless you're doing shenanigans with ioctls to devices or direct access to kernel functions, the kernel does not really matter - everything goes through user32 and friends anyway, so as long as MS does a good job keeping this abstraction layer stable OS upgrades don't concern you much.

danbruc 9y ago
[...] as long as MS does a good job keeping this abstraction layer stable OS upgrades don't concern you much. The problem is that you have to keep them stable to a much higher degree than you might think at first. Obviously you have to maintain the functionality as described in the API documentation but that is far from enough. If the implementation has a bug, you can not simply fix it because there might be software either relying on the wrong behavior or having implemented workarounds that you might break with the fix. And no matter how often the API documentation states that this or that is not supported or undefined behavior there will be software doing it anyway or relying on what ever undefined behavior meant in the version they developed against. You return a list of something and say nothing about the ordering in the documentation but as an implementation detail it happens to be in some specific order, if you wait just long enough there will be a program critically depending on the ordering you choose. This is an endless nightmare especially if your APIs have as many different consumers as the Windows APIs.
whoopdedo 9y ago
Out in the wild though everything doesn't go through user32 and friends. Antivirus in particular is notorious for ignoring public APIs.

yesenadam 9y ago

>This was considered an important thing for the product. Backwards compatibility used to be the norm for most stuff, didn't it? In the 80s/90s. You didn't need to get a new computer every few years. Now if there's a problem, the solution is easy - "Buy a new computer/phone/iPad."

dingo_bat 9y ago
> Backwards compatibility used to be the norm for most stuff, didn't it? I think this seems true only because of Microsoft. I cannot recall any other major OS spending so much effort on backward compatibility.
- cesarb 9y ago
  > I think this seems true only because of Microsoft. I cannot recall any other major OS spending so much effort on backward compatibility. The king of backward compatibility is probably IBM. AFAIK, their mainframe operating systems can run unchanged software from before MS-DOS was born.
  - wilsonnb 9y ago
    That's true. You can supposedly run a program assembled or compiled in the 60's on a z14 that you buy today. Seeing as most of IBM's largest customers are banks and other places that have no interest in rewriting battle tested software, it's probably the reason that their mainframe department is still alive.
- beefhash 9y ago
  SCO OSes are also backwards compatible to hell and back.
bpicolo 9y ago
This is one place where the Web continues to reign supreme. Did we re-implement an OS on top of our OS? Sure. But it's been a tremendous success for accessibility.

Const-me 9y ago

Unfortunately, a lot of software written for Windows 95 comes with 16 bit installers. And there's no 16 bit compatibility in 64 bit Windows.

cesarb 9y ago
> And there's no 16 bit compatibility in 64 bit Windows. Since we're talking about the lengths Microsoft goes towards backwards compatibility: https://msdn.microsoft.com/en-us/library/aa384143(VS.85).aspx https://msdn.microsoft.com/en-us/library/aa384143(VS.85).asp... "For older applications that use a 16-bit stub to launch a 32-bit installation engine, 64-bit Windows recognizes specific 16-bit installer programs and substitutes a ported 32-bit version." (However, this is not always enough: https://davidcmoisan.wordpress.com/2010/02/18/16-bit-installer-support-in-windows-64/ https://davidcmoisan.wordpress.com/2010/02/18/16-bit-install...)
- Const-me 9y ago
  > this is not always enough Right, I have one 1997 videogame that uses InstallShield 3.0.95.
eumoria 9y ago
Yea that was the big break in compatibility. There's also many applications that were written for the specific hardware and many undocumented features (hacks) on 95/98 that modern Windows cannot handle.