Hacker News Reader

Comment by intsunny | Hacker News Reader

> 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.

View on HN

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.

> 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.

[...] 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.

Out in the wild though everything doesn't go through user32 and friends. Antivirus in particular is notorious for ignoring public APIs.

>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."

> 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.

> 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.

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.

SCO OSes are also backwards compatible to hell and back.

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.

Sorry, I didn't understand any of those sentences.

I mean that the web has been a tremendous success story for long-term backwards compatibility and widespread access. We've lost a few pieces of technology, like Flash, but overall you can take any modern browser and go visit ages old websites and find them fully functioning.

Here's Bob Dole's 1996 campaign site: http://www.dolekemp96.org/main.htm

Browsers are on every platform, and for the most part different platforms require no different code for your web application to work. Mobile vs Desktop, Android vs Windows, you get it all.

Ohh right, thank you for explaining. Hmm but e.g. a lot of new websites dont work on any available browser on my computer. The problem is so many new sites need a new computer to work properly—as if they're only tested by people with new computers—not that new computers have a problem with old sites. Maybe I should, uh, buy a new computer. :-) But I figure there are as many people using computers as old as mine, as using brand new ones, maybe not. But I've realized there are two kinds of backwards compatibility, thanks.

Hah yeah, forwards-compatibility is a separate issue there.

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.

> 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).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-install...)

> this is not always enough

Right, I have one 1997 videogame that uses InstallShield 3.0.95.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com