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.
Backward Compatibility: Running your COBOL written in 1971 on the current release of z/OS without changes.
FYI: the hardware architecture has gone through 2 addressing mode changes since then - from 24, to 31, and now 64 bit addressing.
You think emacs is evil?! You've never used VM's XEDIT have you?!! That's evil, baby!
Visicalc for the IBM PC
Hopefully in the future (this applies to all OS's, not just Linux) the backwards compatibility issues will be somewhat muted by our ability to run virtual machines to support the old applications.
It seems to come up on Linux under Wine, (wineconsole), but seems to run very slowly and doesn't work beyond getting the initial screen up. Of course, I haven't spent too much time trying to get it to work...
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.
I think the only problem with that is proprietary apps can't statically compile GPL or LGPL libraries, and proprietary apps seem to be the ones that have unfixed dependency issues.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
But they take an OS with less than 70% seriously?
I'd lake to know where you got that 70% figure from. Seriously; the number of applications that actually broke with XP SP2 is tiny.
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
Seems to me that backward compatability issues are an OPPORTUNITY for linux.
Windows API support in linux (ala Wine) not only CAN be done, but it's EASIER for older, frozen, versions of Windows, which are no longer moving targets.
Seems to me that a "tested and seems to work" compatibility list for older Windows commercial apps versus an API emulator/kernel/library version number would provide:
- IT departments with an opportunity to migrate and a starting point for doing their due-dilligence checking
- API emulator project members the feedback they need to find and fix any mis-emulation that is blocking such a migration
- Linux evangelists a selling point
- Management the wake-up call that it is now POSSIBLE to migrate away from their addiction to Microsoft and other proprietary software, and
- Stockholders a hammer to use on management. B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Windwos upgrade aren't smooth either.
Major upgrades at microsoft breaks a lot of stuff. The main problem is their philosophy of backward compatibility which manage to accumulate both the bad side of backward compatibility and non compatibility.
Most of the time, Microsoft tries to assure compatibility by keeping around old APIs over and over across each generation of products, but each time fixes bits to keep up with modification of the underlying technology. You end up with a Windows XP wich is "somewhat" compatible with application written for Win9x, but not quite exactly, because some details have been subtely tweaked during the software evolution. And you end up with situation were you have to test each Service Pack to be sure that it doesn't break any critical application before deploying to the whole company.
Sure, you have to keep as much compatibility as possible so you don't break old apps and can't just scrap everything with each generation, and on the other hand you have to do fixes and introduce new technology otherwise there won't be anything new in a "new" version.
But there are better ways to achieve this. Mac OS X is a nice example, that regulary uses emulation to ensure backward compatibility. Between 68k and PowerPC, between different version of OS and OS X, between PPC and Intel.... each time they make a new architecture offering new possibility, and instead of keeping some old stuff that only drags evolution back, they choose to emulate it, which have the benefit of both keeping backward compatibility, but also isolating legacy code in a sand box which won't interfere with newer generation technology. Bugs that crashed previous version of the OS will only crash the one inside the virtual box. (On the other hand, due to legacy code, some bugs hang around for a very long time in Windows. Such as the "dir nul\nul" bug whitch crashed all the way from very early MS-DOS (3.xx something I think) up until the last DOS-based Windows)
Opensource software on the other hand have a different possibility : because their source is open, users can fork the code, provided there's enough interest to keep a copy of the old version parallel to development on the latest one. GTK is a nice example in user land : GTK 2.0 completly broke the API and ABI of previous version. But most current distribution still carry a GTK version 1.xx which is still maintained and debuged. The Linux 2.4.x kernel tree for various reason (smaller footprint, support for older hardware that was dropped later, etc.) is still maintained and bug fixes and newer functionnality are still backported from 2.6.x because there are enough people to care and because the GPL doesn't forbid them to do it. (It is as if there was a community of Windows 95 user still porting functionnality from Windows XP and fixing security).
With microsoft product, sadly, it isn't so. It's always "windows" but it's not always quite the same windows. Once a product has been end-of-life-ed there's nothing you can do against it as a user (License forbids you), you can only switch to the newer version and hope that the compatibility will good enough and that the "tweaks" haven't broken anything.
On the other hand, thanks to Microsoft, students in university can earn enough money to eat, by helping IT staff to test compatibility between service packs and softwares.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]