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."
I am still working on 2.4 to 2.6 kernel issues. Linux and it's authors have no concept of backwards compatiblity. We have to redo everything and our purchased software suffers even more.
Athiesm is a religion like not collecting stamps is a hobby.
Something's not right with these links ... is someone just trying to /. their own blog here or am I being redirected? The first link is completely off topic and goes to a post about SoftMac (a Mac emulator), the second is just an example of how one company has 9000 legacy scripts that require older version of windows (+ 400 16 bit programs). So what? This hardly seems like the a front page of slashdot argument for OS Backwards Compatibility ... there's really no argument other than stating the 9000 # and the 3 years it would take to convert them.
... in this case Linux would likely become our new O/S.
Pure and simple, Microsoft has protected their market share by remaining backwards compatible, and will continue to do so for that reason only. A company like Apple can afford to ignore backwards compatibility to some extent, as this actually drives greater revenue from their loyal customer base buying new software. Microsoft though, cannot afford to give their corporate users a chance to make a migration decision.
If Microsoft eliminated backwards compatibility, thousands of companies would be in a position where they needed to include the cost of migrating software in the upgrade decision. All of a sudden, Linux would become a viable option for these corporate clients, which Microsoft can't afford. For example, my company currently has over 900 16 bit applications that we haven't touched in ~10 years. Almost all of these run fine under XP and the beta versions of Vista, so upgrading to Vista will be a cheap option. However, if Vista didn't support these 16 bit apps, we'd have to spend years of time and Millions of dollars upgrading
For this reason, Linux advocates (and many others) would love to see Microsoft remove backwards compatibility, but from a business standpoint Microsoft just can't do it.
Crack - Free with every butt and set of boobs
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.)
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.
no point breaking eggs if no-one will be able to eat your omelette
I am looking into a problem we have here where my software works fine with GD 2.0.23. If I upgrade GD to 2.0.28 (compiling from source, not using binaries) my code stops working. Everything compiles fine. Everything links fine. Just doesn't work.
Look at the FOX toolkit. The interface completely changed from 1.X to 2.X. No backwards compatibility. I need to re-write all of my source to handle the new interface.
Just remember - if the world didn't suck, we would all fall off.
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.
Now, if you happen to write code for fun, like me, then you are of course free to chuck it all out and start again. The Fun Factor outweighs the cost, since the cost is free. So govern yourselves accordingly, if you want to make money, then do as little as possible to develop the code, if you are in it for love and glory then do it for yourself.
Dominant Meme
I put my CD in backwards and it worked just great in Windows. What needs some hard core journalistic investigation is Windows Upside-Down compatibility.
Trust me in a corporate setting not having backwards compatability is a big deal. For home users it is even worse.
/. after all), even if you like the new OS and it's features, do you really want to have to replace every app you've got because they don't work properly anymore. Yes VM solutions can mitigate a lot of this, but those solutions are not perfect.
If you loose backwards compatability you run into the same problem that all the smaller OSs have in getting the corporate world to adopt them on a larger scale. An IT manager may be able to convince the bean counters to give enough money to do the OS swap, but try asking them for the money to have to swap every application you have as well because the old ones won't work anymore. Then on top of that try getting the funding and the authorization for the time to retrain all your employees on new applications that they are not as familiar with. Beyond that, productivity will go down for a while until people get used to the new systems even with training. Now if the new system is truely more efficient (from a worker bee point of view in time to complete a task) this may eventually pay for itself, but do you really think most upper managers are going to be that patient before firing the IT manager for screwing over the entire company's productivity rates? If you do then you are dealing with much more patient managers than I am used to or just folling yourself. That is the true cost of loosing backwards compatability, especially when a large number of your key applications are built in house, then you can't just go purchase the new version that will run on the new platform with minimal retraining needed. For companies that develop a lot of thier own applications in house, you have a lot of down time until the IT departments can recode to whatever new standard the new OS requires.
Home users are better and worse off in some senses. While a lot of home users will probably just buy the new versions of major software (office software, email, etc.) when they purchase a new computer that still adds a lot to the cost of a machine. For the more technically savvy people out there (this is
I was one of the people that MS picked up on a 6 month contract for the extra support load when XP SP2 came out. Take it from someone who was there, the biggest complaint (especially from corporate customers) was when it broke compatability with old apps they were using. I heard a lot of people (and people I knew personally) say that they would install SP2 once the compatability issues were fixed when they eventually swapped to a newer version of the key app that they couldn't live without. Now MS did fix some of those issues with patches shortly after SP2 came out, but imagine that problem scaled up to replacing an entire OS without regards to backwards compatability. I know everyone around here likes to bash MS, but they are not nearly stupid enough to piss off thier corporate customers that badly. They know that would be the fastest way to push people away from Windows in a heartbeat, or at least to insure that not many people bithered swapping to the new version instead of just staying with what they already had that works.
(+1 Yum.)
The Statue of Liberty is America's lawn jockey.
Allow me to do a variation on a Balmer-related meme:
Dependencies! Dependencies! Dependencies! Dependencies! Dependencies! Dependencies! Dependencies!
I'm a broken record on this subject, but I've had quite a few nightmare compiles on Linux that have resulted in me abandoning it on my laptop in favor of Windows. At least there the software I want to use works. They have *got* to fix that problem if Linux is going to become a mainstream desktop product.
120 characters for a sig? That's bloody useless.
"For MS, backwards compatibility is delusional lip service - but that is what IT managers like, after all."
Er, have you ever worked in software or IT? Microsoft place the highest emphasis on backwards compatibility, running 16 bit software in virtual machines and 32 bit software natively. I'll ignore your inane comment about IT management, since you sound like you're just making stuff up anyway.
Can you explain the precise mechanism of this Unix binary backwards compatibility you're talking about? I work with Linux every day and have since 1998. I'm pretty sure if I grabbed a version of, say, Postgresql from those days and tried to launch it now, it wouldn't work, nor would it even compile. Same with any gui desktop app or driver. I haven't worked a lot with AIX or HP-UX since the '90s, but I'd be pretty surprised if a CDE app from 10 years ago just fired up without any problems.
You're sort of missing the point here though. This statement is pretty common in the Linux world... "all you have to do is recompile..." ALL you have to do? Really? All I have to do is re-compile? Assuming I have the proper kernel to begin with, and the proper libraries, along with all their dependencies... I just want to run a program man, I don't want to become a programmer just to use my computer. (90% of office workers speaking, I.T. specific roles excluded)
./configure or ./make or whatever, his eyes will glaze over and he'd rather spend a million dollars on a setup wizard app than have to go to school just to learn how to install a free app. Not to mention the fact that 6 times out of 10, you'll get an error and have to track down what went wrong and fix something before you can attempt to compile again.
The truth is that compiling a program (under ANY platform) IS rocket science level stuff as far as computers are concerned. Yes, a programmer does it in his sleep (as do most Linux daily users). But Joe CEO and Jack employee can click next all day but the moment he has to type
Compiling source to a binary IS complex stuff despite what any mainstream Linux supporters might think. And having to re-compile something EVER, WILL keep it from being accepted main stream.
I've even heard people say "well all ya gotta do is just make your own kernel and there ya go, piece of cake". As easy as that might sound for the Linux guru, that is exactly equal to telling a driver to build their own car. Plenty of mechanics out there that can do it, yes, but EVERYONE isn't a mechanic nor should they be. People who build their own kernels and compile software are the mechanics of the computer world and shouldn't expect all computer users to be mechanics.
I for one do not ever want my bosses to be as 'smart' as us I.T. guys are. Why then would they have any use for me if THEY know how to compile a kernel? If the world was so enlightened as some people seem to want it to be, then a lot of people would be without jobs because their skills wouldn't be needed.
Don't get me wrong though, I'm not saying one way is the end all better way, I'm just saying that as long as the corporate world is run by people who just 'want it to work' (which will be forever) software that requires the user to do the programmers job will not fly. All my servers are Linux servers, but that's only because myself and the other techs here are skilled at making them work. I wouldn't DREAM of putting Linux on our desktops. Are you crazy?! Will YOU then be the one who baby sit every soccer mom who comes to work for us and teach them how to use it for free?
If products could be packaged such that they get compiled during install, but in the background with the user being none the wiser, then it might fly. Like say your installer went out and did all the work on its own of gathering the required libraries while the user only ever saw a wizard with a next button.
My two cents, take it or leave it...
[ http://www.dvigroup.net/self ]
With Free/Open Source Software, you are free to upgrade the applications with the OS, and it's the distros' business to make it work.
In an enterprise Environment isn't always as simple as upgrading to the latest bleeding edge Linux, downloading the newest software versions, compiling, installing, uploading your configs and scripts and everything works flawlessly. That's the point TFA was making. Unless your distro is 100% backwards compatible (ok, 90% compatible, there are always problems) back to, say... the 2.2 kernel many corporations won't take Linux seriously as a solution because the cost of debugging the problems that accompany each upgrade because of broken compatibility issues would be prohibitive. Today some Enterprise grade Linux distro's offer this kind of a guarantee, at least up to a point. So if you have ever wondered why people shell out all that money for RedHat SuSE and Co and their Enterprise quality distributions when they can download Slackware for free, that's **one** of the reasons why. While they may not be on the bleeding edge technologically or perform as well some other distributions, the stability and continuity these Enterprise distros offer reduces costs appreciably.
Only to idiots, are orders laws.
-- Henning von Tresckow
Even after billions and billions of development dollars Microsoft still breaks lots of applications on their major releases. I've been working on a server 2003 system that we've had to tweak and fiddle with for over a month to get a couple of applications to work properly, and we're still working on them. There are a couple more that will not work and have to be abandoned. These are older applications, so that could be the problem, but they were running on server 2000. No one can tell me that they are 100% compatible, because they are not.
Which would I rather do, try to get a program to work that is proprietary on a proprietary system or open source on an open source system? Hmmmmm. Let me think.
Also, if you want an open source application be backward compatible, send a little money to the authors. I bet you'll get a much better response from them than you would from a company that charges you an arm and a leg for a proprietary application. Try getting Microsoft to make a change to their system! Even large companies have to usually take what they get pushed on them from Microsoft.
The fix is simple, but most people argue against it. Use shared libraries where appropriate, and static libraries where it makes sense. The argument for shared libraries everywhere is that it saves disk space, and it makes updating all your apps easier by just upgrading the libraries they depend on. This is ok for widely deployed and tested libraries, where it is very unlikely that something will break between minor versions. But if a library is likely to be used by only a handfull of apps (such as audio / video codecs), then by all means compile them into the app. That way you reduce the number of dependancies and the breakage, at the expense of a bit more disk space used and the inconvience of upgrading a few more packages when a bug is found in the library in question.
/soapbox ]
Note, that this is mearly an issue for third-party packages for your os. Everything that comes with the os can follow whatever rules is best suited for it, as the whole thing is developed together. But I see no advantage to having to track down and install a dozen seperate library packages in order to get a particular app installed, esp. if those libraries are use _only_ by that app. Also, the worst offense a package can commit is to require major updates to packages that are included as part of the os. If the os ships with a supported version of libfoo-1.7.2.so, then the app package should be compiled against that version and not against (and requiring) libfoo-1.7.5.so (or worse, libfoo-1.8.x.so), instead if it actually requries functionality that is only present in the newer lib version, then it should ship with a private copy either statically linked, or installed in the app's lib directory. Because if something else uses that lib, chances are it will need libfoo-1.7.4.so, and be incompatible with libfoo-1.7.5.so (even though minor version increases shouldn't break compatibility, but it happens anyways).
[
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