The Importance of OS Backwards Compatibility 380
gbjbaanb writes "Raymond Chen (of ancient Microsoft heritage) has a blog where he describes some of the things he's worked on, as well as oddments of obscure code and design decisions in Windows. Regardless of what anyone thinks of Windows, it is informative and often thought-provoking. Recently, Raymond posted an entry about backwards compatibility, and why it is such a big deal for large corporations. Something that I have read about on Slashdot regularly (where Windows is criticized for bothering with it at all), I thought readers would be interested in exactly why Microsoft spends so much effort on backwards compatibility, and by inference, why it is an important topic for getting Linux adopted by big business."
Re:Windows Backward Compat? (Score:5, Informative)
Absolutely. Probably the best in the industry. You can still run Visicalc on any Windows machine.
How do you explain the travesty that is Vista? (Score:3, Informative)
Re:Huh? (Score:3, Informative)
There are some real gems in there and if you are serious about software development you should probably just read the whole blog. Doesn't take that long and you can skip the more personal posts if you like.
Incorrect (Score:2, Informative)
Re:How do you explain the travesty that is Vista? (Score:3, Informative)
Re:How do you explain the travesty that is Vista? (Score:1, Informative)
Re:I admit to have not RTFA, but (Score:2, Informative)
I wrote a 32 bit SCSI target driver in the early-90s using the (then deprecated) Solaris 2.3 ABI and it worked flawlessly until the early 2000s when we were required to switch to a 64 bit kernel, a switch we had delayed since the 90s.
The company still runs a version of Oracle compiled for Solaris 2.2 (1992?) and it works flawlessly, except it has a bug in its use of log archiving that was masked by earlier versions of the UFS. They still run the 14-year old 32 bit Oracle binaries on a 64 bit Solaris 8 box.
Backword compatibility is critical in the enterprise, and honestly, much of the OSS world ignores this.
Re:With open source the same problem exists (Score:1, Informative)
There are two possibilities: either later versions introduced a bug that breaks your code, or your code does not follow the spec correctly and relies on a bug in the earlier version.
> Look at the FOX toolkit. The interface completely changed from 1.X to 2.X.
The FOX toolkit is not 'Linux'. But help is at hand. Just make your code link to (libraryname).so.1 and it will not use the
Re:With open source the same problem exists (Score:3, Informative)
Re:With open source ... (Score:3, Informative)
Looks like I'm arguing against it.
Those who do not understand package management are doomed to reimplement it, poorly. Although you do make a point:
Perhaps, but most distros now support adding third-party repositories, and even if you don't, when you download a .deb file manually, it's still going to pull in dependencies when you install it.
Ultimately, I see compiling things statically as being kind of like offering a WinZip Self-Extractor file for a Windows XP program. Ok, it's guaranteed to work, but it's still a bit of pointless waste.
And by the way:
There are multiple, very good ways of dealing with this. The libfoo guys shouldn't have broken compatibility, or should've sat around and come up with all the ways they'd like to break compatibility and put together libfoo-2.0.0. Or, the package that's incompatible with libfoo-1.7.5 could depend on libfoo-1.7.4 -- both can easily exist on the same system. Or you could just not symlink libfoo-1.7.5.so to libfoo-1.7.so or any of its other aliases -- packages that know about 1.7.5 can link to the 1.7.5 version, packages which don't know about them will stick with 1.7.4 automatically.
All of this can be handled by a distro maintainer, so a really simple solution for most of these problems is to simply find a way to allow your app to be distributed, or if you can't do that, pay some developers to maintain parts of the distro that your app cares about, and keep everything compatible.
And audio/video codecs should not break compatibility between versions... period. How simple can you get? But if you let your app use a shared library, that means your app could automagically get any codec I install with the system.