Slashdot Mirror
The Importance of OS Backwards Compatibility
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."
Do people really think Windows does a good job with backward compatibility?
Absolutely. Probably the best in the industry. You can still run Visicalc on any Windows machine.
We have several in-house apps that were written recently enough to be done in C# and none of them work in Vista. We have two guys working to convert them and they've had no success after spending dozens of hours on the problem.
Raymond Chen's blog is worth reading for the technical posts, and the most interesting ones are about Windows reverse compatibility or why certain Windows API things are the way they are, but there is no one link that you can give for them. That's probably why the submitter's links seem unfocused. His blogging software doesn't seem to have any categorization.
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.
OOo chokes on Mac Word files from 5.0 and before, and 5.0/Mac was a huge segment of the Word market in the 90s. The current MS Office apps on both platforms can read them. Trust me, I've tested this extensively. Sun has gone on record that they don't think pre-6.0 Word files for Mac are any kind of a priority for OOo, although they hint StarOffice might be able to do it.
"Made up/misattributed quote that makes me look smart. I am on
I appreciate where you are coming from and I cannot comment on AIX or HPUX, but I can comment on Solaris. Sun has been fascist about binary backword compatibility.
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.
> my software works fine with GD 2.0.23
.so.2. You are not forced to use the latest version.
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
why this is modded funny is beyond my understanding: Debian supplies its releases with updates for _ALL_ the software included. Oldstable still includes KDE 2.2 .......
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.
Don't thank God, thank a doctor!