6 ms·

> private\inet\wininet\urlcache\filemgr.cxx: > // ACHTUNG!!! this is a special hack for IBM antivirus software Why should Microsoft produce a hack for an IBM a

> private\inet\wininet\urlcache\filemgr.cxx: > // ACHTUNG!!! this is a special hack for IBM antivirus software Why should Microsoft produce a hack for an IBM antivirus product? That IBM software might be used by a few tens of thousands of people for a few years, whereas Win2k impacted billions of people and will continue to do so. At some point it is likely the programmer, PM, and maybe even the bug tracker behind this code may have moved on, and a newer generation of contributors will have to waste time understanding the bug, and deciding to support it or not. Possibly without ever knowing if IBM has fixed their own bug, or still uses that antivirus software or not.

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.
pjc50 9y ago
Microsoft do this all the time, because big institutional customers don't upgrade otherwise. If this horrifies you wait until you hear about the Vista compatibility modes.
B-Con 9y ago
I bet someone at IBM found a bug, traced it back to some quirk in Windows that was hard/impossible to work around and the ticket got the attention of an engineer who figured out how to fix it in less than an hour. They decided the change was benign so they did it, commented it for posterity, and moved on. Microsoft actually has a reasonably close relationship with large companies that develop on their platform. eg, their plug fests for devs to come put their stuff onto the same machine and see how they all inter operate on new versions of Windows. I used to work semi-closely with someone doing Windows driver work. He knew a lot of quirks in the platform and even could escalate to the point of getting help from kernel engineers.
- cesarb 9y ago
  Windows 2000 is from a time when software distribution was still mostly in the form of physical media, and everything having an internet-enabled updater was not as common. The IBM software in the comment was probably written for a previous version of Windows, and if a new version of Windows wasn't compatible with that IBM software (as found in the box the user bought), it would present an obstacle to upgrading to the newer version of Windows for users of that IBM software. Users wouldn't be expected to upgrade every boxed software they had bought just because they upgraded Windows.
  - mikeash 9y ago
    There’s also a psychological element. When a user upgrades Windows and some software breaks, they immediately think “the new version of Windows sucks!” and tell all their friends. They neither know nor care that it’s actually a bug in the software that didn’t manifest before.
- HNSucksAss 9y ago
  Microsoft was very cooperative with developers. Back when their support was done over CompuServe, a Microsoft engineer sent me some internal tools and special builds of Windows components on his own say-so. Very cool and very effective. Obviously not practical anymore, perhaps.
kalleboo 9y ago
The reasoning from someone who works at Microsoft on this kind of stuff: https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=41363 https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=...
dingo_bat 9y ago
https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=41363/ https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=... This may answer your query. Microsoft takes (took?) user-friendliness as the most sacrosanct thing. Breaking a user's apps is the biggest anti-user thing to do. In hindsight, it has maybe turned out that taken to extremes this approach is not sustainable. But I agree with the basic logic.
- eequah9L 9y ago
  Linux the kernel does something similar. I'm not sure about e.g. layout of what various /proc files produce (though it wouldn't surprise me if that were cast in stone as well), but syscalls in particular are compatible waaay back. glibc and a handful other libraries are also careful not to break binary compatibility, providing versioned symbols for old binaries. Beyond that it tends to suck, with some libraries not even bothering with sonames.
- gspetr 9y ago
  I think a solid argument can be made that Microsoft has abandoned this strategy. If they had not then the forced timed restarts of Win 10 (30 minutes and kiss your work goodbye), along with forced updates would not be a thing.
onion2k 9y ago
Why should Microsoft produce a hack for an IBM antivirus product? If a user upgrades their OS and something breaks they blame the OS upgrade.

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.

pjc50 9y ago

Microsoft do this all the time, because big institutional customers don't upgrade otherwise. If this horrifies you wait until you hear about the Vista compatibility modes.

B-Con 9y ago

I bet someone at IBM found a bug, traced it back to some quirk in Windows that was hard/impossible to work around and the ticket got the attention of an engineer who figured out how to fix it in less than an hour. They decided the change was benign so they did it, commented it for posterity, and moved on. Microsoft actually has a reasonably close relationship with large companies that develop on their platform. eg, their plug fests for devs to come put their stuff onto the same machine and see how they all inter operate on new versions of Windows. I used to work semi-closely with someone doing Windows driver work. He knew a lot of quirks in the platform and even could escalate to the point of getting help from kernel engineers.

cesarb 9y ago
Windows 2000 is from a time when software distribution was still mostly in the form of physical media, and everything having an internet-enabled updater was not as common. The IBM software in the comment was probably written for a previous version of Windows, and if a new version of Windows wasn't compatible with that IBM software (as found in the box the user bought), it would present an obstacle to upgrading to the newer version of Windows for users of that IBM software. Users wouldn't be expected to upgrade every boxed software they had bought just because they upgraded Windows.
- mikeash 9y ago
  There’s also a psychological element. When a user upgrades Windows and some software breaks, they immediately think “the new version of Windows sucks!” and tell all their friends. They neither know nor care that it’s actually a bug in the software that didn’t manifest before.
HNSucksAss 9y ago
Microsoft was very cooperative with developers. Back when their support was done over CompuServe, a Microsoft engineer sent me some internal tools and special builds of Windows components on his own say-so. Very cool and very effective. Obviously not practical anymore, perhaps.

kalleboo 9y ago

The reasoning from someone who works at Microsoft on this kind of stuff: https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=41363 https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=...

dingo_bat 9y ago

https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=41363/ https://blogs.msdn.microsoft.com/oldnewthing/20031224-00/?p=... This may answer your query. Microsoft takes (took?) user-friendliness as the most sacrosanct thing. Breaking a user's apps is the biggest anti-user thing to do. In hindsight, it has maybe turned out that taken to extremes this approach is not sustainable. But I agree with the basic logic.

eequah9L 9y ago
Linux the kernel does something similar. I'm not sure about e.g. layout of what various /proc files produce (though it wouldn't surprise me if that were cast in stone as well), but syscalls in particular are compatible waaay back. glibc and a handful other libraries are also careful not to break binary compatibility, providing versioned symbols for old binaries. Beyond that it tends to suck, with some libraries not even bothering with sonames.
gspetr 9y ago
I think a solid argument can be made that Microsoft has abandoned this strategy. If they had not then the forced timed restarts of Win 10 (30 minutes and kiss your work goodbye), along with forced updates would not be a thing.

onion2k 9y ago

Why should Microsoft produce a hack for an IBM antivirus product? If a user upgrades their OS and something breaks they blame the OS upgrade.