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."
There is a bit of a "you rub my back..." going on when Microsoft maintains backwards compatibility. While MS is still the 800-lb Guerrilla, they have an audience with which they collaborate to some degree to make billions of dollars. MS holds the reins, but the team would refuse to pull at all if Microsoft cut them all of at the compatibility pass -- that would guarantee a stampede to find alternatives in OS implementations.
I don't think many are aware how hard Microsoft has to work to maintain compatibility... I once talked with one of the MS engineers -- he said much of the OS code has preamble code to run through a giant "case" statement to accommodate and make allowances for either bad or incorrect coding by outside developers, or bugs in their code that don't execute correctly for the outside software. It's a lot of baggage to carry around, but it's baggage worth billions of dollars.
Interestingly (to me) is I don't think Linux's big task yet is to maintain backwards compatibility with Linux programs (though that would be nice, and seems to mostly be a given anyway), I think the bigger task for Linux is to maintain backwards compatibility with Microsoft programs, specifically legacy Windows software. Unless and until that hurdle is cleared, Linux will always be #2, or #3, etc.
(Sorry for the paragraph of metaphors.)
(Also from an ancient Microsoft experience.)
Microsoft's continued existance has ALWAYS depended on cash cow products such as MS-DOS, Word, Excel and Windows. The only way that a product goes from concept to cash cow is through multiple releases which are sold to end users, offering the vital feedback to improve the product and market preparation to need the product. The only way a cash cow does not turn into a dead cow is through multiple releases which are sold to end users, offering newer features for devotees and fixing some of the most egregious integration problems for enterprises. Without new versions, people grow out of a product. Users adopt a new methodology entirely, or adopt a new product from someone else.
An update treadmill necessarily requires that the updates keep coming. Users cannot adopt a new update unless it is nearly seamless to synchronize and integrate with the other treadmills they are running.
[
Backwards compatibility is important, but there are two ways you can do it.
One is to include all of the old stuff in your new OS, the other is to continue to support the old version, or possibly emulate it on the new version.
It seems that backwards compatibility significantly impedes progress. Why not continue to support the older versions, but separate them from the new stuff? Our computers are fast enough to run Windows 3.1 in a VM, much faster than it would run on the hardware it was designed for.
Better yet, include a copy of the old software in the new one, with a built in emulator designed to run it.
It's important to maintain backwards compatibility, but it's just not a good excuse for bad design decisions in new softare.
If moderation could change anything, it would be illegal.
Just know that while your 16 bit apps will run under Vista, but this is only true for the 32bit version of Vista, as your programs will always fail to run in the 64bit version... This may not be a big deal now, but it could become a problem as 64bit processing becomes more common.
Then why upgrade the machines running the legacy apps / scripts at all? It's not like the older versions of windows don't run fine. Making sure they're not connected to the internet is all you need to do to make them secure, or if that's not viable then heavily restrict their access with a firewall (preferably hardware). After all, why should a weather data sensing and reporting machine (for example) be able to connect to anything except the database it's sending the data to? Why should it be able to get any incoming connections at all? Even running unpatched windows 3.0 it would be safe if set up like that.
Do small in-line hardware firewalls exist? Just with an incoming and outgoing RJ45 socket and a hardware circuit that only allows data through to or from a single ip (or range)? I can see many businesses could use these.
So don't upgrade major versions. Something breaking between 2.0.23 and 2.0.28 is a bug, and should be filed and treated as a bug (unless it was your error). Have you done that? Important applications should undergo testing when new releases of libraries come out, specifically to catch issues like this. The fact that your testing picks up problems doesn't mean there's a flaw in the process. This demonstrates that the process is working. If you had simply upgraded all of your clients with the assumption that things would work, that would indicate a flaw in the process.
Something breaking between 1.x and 2.x is expected. A lack of compatibility is expressed right there in the version number. Major projects will keep each major version going independently for some time. You should continue to see bug fixes in the 1.x line even though 2.x is out, provide demand and interest is there.
It's also open-source, so you're free to keep your own development and bug fixes going if you can fund it yourself.
This is one of the reasons "Solaris is better than Linux." There are few things that we've deployed on Solaris 2.5 (possibly none, but I won't swear to my memory) that don't also work under Solaris 10. This is a far cry from the Linux 2.4-2.6 headaches we've experienced.
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
After seeing how bad the "converter" was we quickly abandoned the idea of automatically converting to VB.NET or anything else. Even in principle there are many problems with automatic conversion such as issues caused by the fact that objects lives are no longer so predictable (reference counting vs Garbage Collection). And if you have tried to do clever stuff in VB6 to get around its limitations (like we did), you are really in trouble.
.NET consultant and I have since found out that they had such problems communicating between the different .NET and VB components that they resorted to communicating via the database in some awkward way (I shudder).
.NET. Sun are actually interested in having a cross-platform system whereas Microsoft are too tied up with pushing Windows. And now that Java is going fully open-source, it's an even more attractive option.
So we also decided the best thing was to rewrite things component by component, or at the very least write all new components in C# and use INTEROP. However, we found interop to be absolute hell. After I left the company they hired a
I suppose that as long as you stick to developing using Mono and as long as Microsoft do not shut Mono down in the future in some legal attack, developing with C# is safe. Obviously if you develop using Visual Studio you will end up using all sorts of things that won't work with Mono. Even so, the fact the Microsoft dumped a language that so many people were using does not fill me with confidence.
Obviously Microsoft has a lot of momentum but if I were in charge of a business I would sooner choose Java than