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."
You've got to break a few eggs to make an omelette, I always say.
For a tasty omelette, add cheese, tabasco sauce, and ground black pepper.
Get your own free personal location tracker
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.
-b.
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
If corporate data was stored in more open format legacy applications would not be such a problem.
UNIX/Linux Consulting
on the surface, this seems ridiculous.
Free Software - and also commercial UNIX to a great degree - has the highest standards of backwards compatibility - far more rigorous than anything Microsoft has come up with.
MS' idea of backwards compatibility is hampered by an ever changing filesystem layout where developers are encouraged to step on the OS as well as other apps. It does not work and never has. For MS, backwards compatibility is delusional lip service - but that is what IT managers like, after all.
It all goes back to essentially the UNIX focus on adherence to protocol standards, and the MS focus on profit - and a big part of that is breaking protocols to force obsolesence.
One of the problems with maintaining backwards compatiblity in Windoze is that the whole mess evolved by acreting guano rather than having a clear path for upgrades. That is define where the various modules will interface with each other before you start coding.
Perhaps I misunderstand, but is the submitter trying to say that Linux should learn from Windows in this area? Backwards compatibility is one of Linux's strong points, and Windows' performance in the area is terribly weak. Where are these people complaining about Microsoft spending TOO MUCH time on backwards compatibility; I've only seen people complaining about things being broken with every upgrade.
Raymond's blog is interesting, though. I'm glad to see someone at MS interested in backwards compatibility.
Yeah, and you'll also see posts by people who don't understand all sorts of basic concepts.
Why complain about them? Why even bother to mention them at all?
Whether you need backward compatibility has never been in doubt. You simply cannot expect your customers to re-enter all their data every time you issue a patch.
The question is whether you should bring the old bugs forward for the sake of "backwards compatibility".
Personally, I believe it should be more of a case of killing the bugs with a new major release and treating it more as a "migration" than an "upgrade".
Compatibility freak?
Retro chic
Tweak the hardware
Old-school sleek
Burma Shave
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.)
Actually, I see a much bigger need to be able to access information than to be able to run old applications. The big problem in all of this is that a lot (if not all) legacy applications have closed data repositories so being able to run those applications in a modern OS is imperative.
Why the "copy" command is still broken after all these years. Someone lose the source?
And speaking of open source, I am building a new bsd box to migrate users to since the original admin missed a year of upgrades and the pieces cannot be upgraded now without serious downtime.
Ah well. If *nix had backwards compat, we would have the millions of compromised zombies on unpatched boxes.
*"Cogito Ergo Liberalis"*
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.
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.
(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.
[
aside from some stuff that latches on to the kernel (antivirus and drivers mostly), I've found windows to have very good backwards compatability...
Forward compatability (windows using software written for later versions), unsurprisingly, sucks.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
I can run the original Visicalc on Windows XP Pro. Can you name one 27 year old program that you can run on a Mac? I know you can't do that on Linux without having to re-compile, which isn't at all acceptable for end-users.
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.
he says, This isn't a company that bought some software ten years ago and don't have the source code. They have the source code for all of their scripts.
this is a bit confusing to me. is he saying they have the source code of the apps and the install scripts or that they have the 'source code' of install scripts only? and if so- wouldn't that just make sense? Are there people out there running some kind of binary install scripts that they can't read themselves?
my next question is this - is the need to run older apps one of cost, or one of technical complexity? i ask this because my initial reaction is that, when i don't want to upgrade something it is usually because i don't want to pay for the new version, if the old version meets my needs. with the open source software i use, i may hold off on an upgrade until i'm sure it is stable, but then i go get it. i understand that in the corporate world it isn't that simple, but is it so complicated that this blog post is accurate? would it still take three years to get their software to install on a new setup if the software and os were both open?
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
Personally, I don't use Windows. I am a self admitted Mac fanboy (OK, also a professional mac developer for the past 10 years.) However, I love diversity. I like the fact that Windows provides the ultimate in backwards compatbility because I can related to the fact that for some businesses, backwards compatbility is the most important thing.
I love the fact that Windows and Mac and Linux exist. I wish that Amiga and Be could still be serious choices. Because more choices is better.
Avoid Missing Ball for High Score
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
While this all makes sense, and some Linux distros must be sensitive to the practical requirements of these corporations, there is another side...
It is very useful if you can, occasionally, break backward compatibility. With time, it becomes apparent that past decisions were a mistake. Being able to correct some of those mistakes, and do it in a reasonably clean way, makes for a better system.
So I wouldn't say that backward compatibility is a rule. After all, lot at MS with dotNet. dotNet 2.0 is not backward compatible with dotNet 1.0. If you want your 1.0 program to run on 2.0 you will need to make changes. But you can keep running your 1.0 program on the 1.0 stack which sits side-by-side with the 2.0 stack. In this way they allow for backward compatibility but they also allow for compatibility breaking changes.
It is the best in the business, period. Ancient software (i.e. Windows 3.1, 16 bit stuff) will normally run on modern versions of Windows with few if any problems.
Well, as far as basic filesystems ... Micro$oft has done pretty well...
I'm guessing that good old FAT-12 (floppy) filesystem from the 1980's is still supported in Vista, right?
FAT-32 and the more-than-eight-letter-filename system from Windows-98 (95?) is also supported in Vista.
But I guess, almost everybody still supports lots of old stuff...
I think Linux still supports the old Minix partition type
The latest & greatest VMS release can still read & write old VMS hard disks from the 1980s also.
Thomas Dzubin
Karma: Excellent. 15 moderator points expire sometime.
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.
You need backward compatibility because people still use old apps. You need to eliminate backwards compatibility to get rid of bloat. Seems like the answer is to make the legacy features into optional packages that sys admins could choose to install or not install based upon their needs. They then could balance security against functionality. They could also clearly see what they needed to ask developers to upgrade first. (If we upgrade APP X, we can uninstall LEGACY PACKAGE Y)...
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.
Because I know they need it. Without compatability with old Windows software, the next buying cycle every CTO on earth would have a chance to consider whatever operating system they wanted since all would involve switching to entirely new software, as opposed to now where buying Windows to replace Older Windows is the automatic choice. It isn't just Window's market share that maintains there monopoly, it's the resulting market share of software for Windows that really does it. Drop that, and Windows' real advantage is gone.
I do make fun of them for not being able to stabilize and secure some of the old code, though I understand it's tough when the code is old, complicated, and crufty, and a lot of old programs require "bug for bug" compatability.
I think the solution for them is deprecation. Old interfaces that are stuffed with crufty code, and which were often insecure by design anyway, should simply be made unavailable for new applications. You have an old app that wants to use it, fine. You want to code a new app using OLE or ActiveX or what have you? Tough. Eventually software gets replaced, and eventually you wouldn't have any software using the old systems and you could disable them. Sadly there's still plenty of new development using ActiveX and other crap, so MS both shows no interest in doing this nor may they be able to.
Now how does this apply to Linux? In Free Software Happy Land, you have the source to all the software on your system, so with the ability to recompile you don't need binary backward compatability. Being able to link your source code against new libraries can fix a lot of the problems with having to support really old binaries. There's still the issue of interface compatability (which is tied up in binary compatability in the Windows world), but a lot of the interfaces are stable.
This isn't Free Software Happy Land, though, we're talking about businesses. Personally I think that adopting Linux should also come with adopting some of its philosophies, in particular that having source code is much much better than not having it, so if you aren't getting source then it had better be much much better than the program you can get with source. Linux does not have a strong history of binary compatability, and I'm not sure it's best for Linux to start establishing such a history. Business may not like it, but maybe they need to adapt to Linux not the other way around. Who knows, they might figure out that they like getting source code from their vendors and accidentally discover a better way to do things.
The enemies of Democracy are
Not only do I think backwards compatibility is very important, but ease of use and being able to use existing hardware are just as important too. I am putting Ubuntu Linux on a few machine for some folks right now and so far it's been going pretty smoothly. Hopefully, I can get my mother-in-law switched over so that she can not only keep her current machine BUT she can stop getting those damn spyware infestations from those crappy screensavers she just loves. LOL.
IMHO, IANAL, TINLA, etc...
And if Cain had been nicer to Abel we wouldn't be having the wars we are? But since we don't, wishing that the world was something it's not is useless.
Yeah it sure is a shame big business won't use Linux because it's not backward-compatible.
Oh wait.... it is, and they do.
Next story.
Backwards compatibility is one of Linux's strong points
Do you have an example of a 27 year old program that can run on a current install of Ubuntu, without having to do anything else? I'm looking at Visicalc on Windows XP Professional right now.
Pick any random Linux distribution or *BSD and you will find many "30 year old programs"
Well that's a good argument, isn't it?
Stop being stupid - most 16 bit windows software does NOT run on windows XP.
Really? Are you just flat out lying in order to accomplish something, or are you really that clueless? Would you like to see a screenshot of what I have running right now, my intelligence-challenege little friend?
Lucky me, I am currently attempting to move a proprietary program compiled with a proprietary compiler in Cobol-74 to a Linux machine from an old sco box.... I've had to learn more about Unix backwards compatibility than I ever wanted to know. :| Ugh.
I'm compiling in linuxabi now... as I type this.
Has anyone else had to do this?
I could certainly use some advice....
torrent plz
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!
No need. The whole program is 27K.
http://www.bricklin.com/history/vclicense.htm
Windows has pretty good backward compatibility for binary programs. In most cases you can dig out a CD or Floppy from 10-15 years ago... or longer, and windows will still know what to do with it. Even with some of the really flaky "copy protection" companies used to build by putting broken code in their EXEs windows will still try to recreate those bugs and run the program. It's quite impressive how much time they spend re-engineering their mistakes in each new OS because you CAN'T update your software for the new OS.. that's the game... it's a "binary-only" world and they try like hell to keep it that way.
Visicalc for the IBM PC
Welcome our new old school Burma Shave overlords.
Backwards compatibility is one of Linux's strong points
Hmm.. you sure about that?
I seem to recall a few issues with this...
ie, multithreaded applications built for 2.4 may encounter problems on 2.6 unless you set some specific environment variable.
Or.. how about the nice compatibility between glibc versions?
As long as you can recompile your software, Linux provides excelent backward compatibility, but that is a non-option for many situations.
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.
You can still run it under Linux (with dosbox)
...solve the biggest issue why companies don't want to upgrade. Yes, there's compatibility testing and user retraining and so on and so forth, but if every 18 months you need to update your glacier-like distro like RHEL/CentOS, Debian stable or Ubuntu LTS, is that really a big hurdle? How much in linux userspace will break? And even then you got 18 months in which to either migrate it or just stay behind - I think the 2.0 kernel is still maintained, if nothing else. Firewall it down and run what you must. Of course, things are different if you have your own embedded thing going with drivers and such it's another hairball. I suppose ALSA, CUPS etc. have changed, but X11 hasn't, have any relevant for a server? Or even a corporate desktop? (ok, printing is rather vital but sound is not. Nor does you age-old machine need to be the one you print from). Linux has had a habit of "let's break it until we do it properly", I remember that with certain GCC versions at least. But that also means that it really does work - you don't need huge workarounds for broken functionality.
Live today, because you never know what tomorrow brings
Lost the source, did you? ;)
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
I've heard once that backwards compatibility on future products would use emulation. In theory, future hardware will be powerful enough to cope with such pratices. And I think whoever said that is right. Either emulation or dynamic recompilation at kernel level si the way to go. If Linux (and maybe GCC too) focuses on these right now, the change to 64bit platforms and higher without backward compatibility will be a breeze, and not a nightmare as some in the industry fear. Food for thought, I guess.
Probably the best in the industry
Only if you ignore IBM. Their customers spend huge sums on very large, capable machines and expect a huge ROI (banks, oil companies, gov't institutions) so there is old JCL and Cobol running on mainframes going back to the 70's. If it doesn't run natively, you can always run it under VM.
I for one haven't found any useful applications I can run prior to mid 90's.
putting the 'B' in LGBTQ+
Solaris has backward compatable binaries back to 2.5. Any binary compiled on previous versions can be expected to run on a later OS.
VMS provides the same comptiblity through a byte level re-compiler, however crossed hardware platforms from VAX to ALPHA and now to INTEL.
Never answer an anonymous letter. - Yogi Berra
vi, emacs, ls, grep, yacc, lex, tex... hella lot of the code is ancient.
Maybe you mean a 27 year old binary? It would be pretty difficult to find a 27 year old binary in the Gnu world, since it's easier to just recompile the binary for whatever system the binary is supposed to run on. Before decrying 'but that's too much hassle for a user' remember: This doesn't have to be done by an end user. I use a all of the above software, and whole lot more, without ever having recompiled the stuff. I installed it all in an automated installation procedure that was easily as comfortable as any Microsoft has ever given me. At the moment this work is being done by dedicated volunteers and a few professionals, but the results are as reliable as those in the windows world, and it's likely that this will change as free software gains more commercial acceptance and investment. It's pretty rare in the free software world for a project of any size to completely stop being maintained. As long as someone is willing to pay a little for support, or (more often the case) if one or more of the users is an enthusiast, the project will continue.
In the commercial software world, it becomes very important that a binary continue to run becuase the source is not available. It can and does happen that some wonderful piece of software gets completely orphaned, becuase the company went out of business (often becuase it could not compete with Microsoft). The users of that application better hope that their binary continues to run on whatever machines they get in the future, because they simply have no alternative. If it stops running, they have to switch to some new software. If the software they are replacing involves story any large amounts of data in some proprietary format, they're in for a tough job... in the worst case paying people for manual data entry. In fact I watched precisely that happen a couple of times while working as a DBA for Reuters. In both those cases, has the software, or at least the data storage format, been free and open, it would have been much cheaper and less effort to pay a programmer to make the necessary changes and recompile.
There are a few lessons to be learned for library writers: Whenever possible write backwards compatible library interfaces. But for the most part this is done pretty well. People rarely change library interfaces without good reason, the code maintainers of reliant projects are responsible to either maintaining access to old libraries, or updating their calls.
It isn't such a huge concern for linux because apps are /typically/ availiable as source tarballs. This means that should an ABI change, the user only needs a rebuilt package. This is also why standards are important, perhaps Microsoft wouldn't have to work so hard at backwards compatability if they stopped deliberately breaking, skirting and extending them!
And quite frankly I think that "open source software" as a whole is suffering tremendously from the lack of this feature. Its also one of the main reasons why I ran from Linux to Solaris the moment their x86 release (Solaris 10) managed to smoothly run on my hardware. Quite frankly, I think this issue alone is causing Linux never to really get onto the Enterprise market.
Just check, for example, Berkeley DB. A commonly used database package, now check how many versions are available on your distribution. Chances are high that you have multiple copies, basicly doing the same thing. However, program A depends on version 2.x while prograb B depends on version 3.x. And because this is a classic example of something not being backwards compatible you're forced to keep multiple copies around.>br>
Who is to blame? No one ofcourse since this is open source software, totally free to use as you feel think or like. Which is IMO the whole problem when you're looking at "open source software" in common. There are no rules, there are no demands and so one cannot expect (or better put: demand) quality. Yet on the other hand people do keep yelling and whining about how great the whole product is and how its capable to compete with every other product out there, from Windows to Solaris.
To those people I'd like to say: Welcome, to the real world.. Linux, as well as other open source operating systems, is indeed very capable and commonly accepted and used. But as we Linux users have kept telling Window users over and over again: Quantity doesn't make quality and it seems to me that this is exactly what most Linux zealots keep forgetting these days. Ofcourse, there is no denying that Linux has booked major successes and is commonly adopted. But its wrong to think that those numbers now tell you that Linux is just as capable as some of its counterparts. Whats that? This thing only happens with "lesser developers" or "evil company like developers" I hear? SO tell me, already forgot how gnu/tar (which I consider to be a key component to Linux) has done the exact same thing when they changed parameters?
Visicalc is a DOS program.
Is the reference that most everyone here is commenting on.
Best case scenario for most sysadmins is backward compatibility is the equivalent of a broad fallow field with landmines randomly placed. Everything else is just arguing how many angels fit on the head of a pin.
I will argue that backward compatibility is something a PHB throws out when she/he wants to say no to something without having to specify their concerns. It's not a reason why the purchase order is cut for your company versus your competitor.
I'm positive I'm not the only one who has had backward compatibility issues with Microsoft apps. IMHO backward compatibility has fallen out of favor for Microsoft. My last nightmare was installing a clustered instance of MSSQL 2000 running on a new win2003 cluster node. Yet there are many fanboys who will claim exactly the opposite.
I also admin Linux servers and find "backward compatibility" is mostly solved with backports. Debian is one distro that provides backports. http://www.backports.org/dokuwiki/doku.php Double-plus goodness right there. If you really -must- have it in Linux, downloading sources and working out libraries is not hard. Time consuming, but not hard. I speak from experience.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
What you certainly don't want to ever do, though, is looking under the hood of Windows. That's where they failed completely. To support this backward compatibility and because they did a lousy job of designing their system, Microsoft has to drag along gazillions of quirks and hacks.
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
Do you have an example of a 27 year old program that can run on a current install of Ubuntu, without having to do anything else? I'm looking at Visicalc on Windows XP Professional right now.
Linux (and indeed Windows) can run quite a lot of old software through emulation, including tons of 27 year old games, Visicalc (using something like dosemu+freedos), CP/M programs under Z80 emulators, and Windows programs under Wine (not that any of those are 27 years old).
In fact emulation is possibly a better way to run old software because you can keep your operating system shiny and new but still run the old stuff. I think this is one thing that the Mac OS 9 -> Mac OS X did absolutely right.
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
How does Microsoft try so hard to be backwards compatible? It seems to me that they try to do the exact opposite, with version lock-in in programs like Word. OpenOffice can handle more versions of Word files than any version of Word ever could.
-- 3till7.net
Chen is the douche who hamstrung progress at Microsoft by mandating that all undocumented behavior should be supported in future OSes. He insisted on a patch to ensure SimCity for DOS could still work in XP.
I see a lot of business whiners here complaining that backwards compatibility is a dealbreaker. Interestingly, none of these people seem to believe a software vendor should be held responsible for their code NOT relying on undocumented behaviors, or a vendor being responsible for patching their apps to remain compatible. When I see PHBs and IT folks holding their vendors as accountable as they do one OS vendor, I'll buy this bullshit.
OS changes don't happen in the dark. MS and Apple repeatedly inform developers what's happening with their OSes, what's being deprecated and what isn't.
You and your customers do not have a God-given right to have seven year old code run flawlessly in perpetuity through OS upgrades. If you don't get this, don't fucking upgrade your computers. No one's holding a gun to your head, metaphorically or literally.
Change happens. Work like it happens or quit bitching.
"Made up/misattributed quote that makes me look smart. I am on
The only problem is that in the Windows world almost everything is closed, proprietary, binary only. And I'm extremely glad that Microsoft has to spend huge amount of resources trying to prevent things from going crazy. They created this sick ecosystem!
And open source is the solution to it.
If you don't fail at least 90 percent of the time, you're not aiming high enough. (Alan Kay)
http://itmanagement.earthweb.com/columns/executive _tech/article.php/3643691
Because, as we all know, IE 7 is an integral part of the OS
putting the 'B' in LGBTQ+
Actually, I can't run it on Vista x64...
Aldus Pagemaker, which was written for Windows 2.0 or Windows 3.1, did not run well on Windows 3.0/3.1. That was 1992. I know this is an old example, but I think that MS's 'backward compatibility' is something that was only retained for some well known and much used applications.
There was also never a good mechanism available to catch those programs that wanted to access hardware directly. Due to that I once rebooted the accounting server by trying to play 'Carrier Strike' on it (Windows NT 4.0/1997).
I also recently locked up my Windows 2000 Professional workstation by trying to run DOS compatible instances of chipmunk log.
Backwards compatibility ? Hah. They may come back on that in 25 years, to see if they can match the backwards compatibility of mainframe class machines, like IBM zSeries, iSeries, WANG, SunOS backward compatibility on Solaris.
No Microsoft operating system has ever been designed with backward compatibility in mind, that was purely accidental.
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...
I thought readers would be interested in exactly why Microsoft spends so much effort on backwards compatibility
Shame they don't do that with other products. They discontinued the VB language (forget about VB.NET, not the same!) and left thousands of companies in the lurch. Millions of dollars were invested in writing VB products around the world and many of the companies do not have the finances to completely rewrite their products again in a new language. I suspect that many of them are keeping quiet since making a big noise about it would frighten both customers and investors.
I was therefore happy to hear that Java is going open source. Perhaps we can now consider it "safe" to use.
Wait what was the question again? I missed it because I was too busy playing Wolfenstien 3D on my brand new Vista box.... Damn that robotic Hitler!
"But this one goes to 11!"
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
Cheap companies using old software is what caused the Y2K problem, and it ended up costing them billions and billions of dollars to "upgrade". Companies need to realize that moving FORWARD, while it might cost a little money, is almost ALWAYS a win. Hanging on to old outdated bullshit systems and software might help the bottom line today, but will end up costing 100x as much in the end...
That's what I was wondering about, all the bad code that has to stay bad to make it all work. Is there no way to write new code to emulate the bad bits so they can remove it? Or a VM to mask the vast swaths of crud?
Is a perfectly cromulent word.
Your point? Since the NT line does not ship with DOS, but a command interpreter, that the NT OS's run DOS programs is a very good indication of MS's backwards compatibility.
"I use a Mac because I'm just better than you are."
Backwards compatibility has enormous hidden costs. Reminds me of the startup I worked for. We used the latest high tech development tools that allowed us to run circles around the big, old, slow competitors. Eventually, one of them was forced to buy us out to prevent them from eating their lunch.
So what do they do then? They start forcing us to use their ancient, out-of-date development tools and processes. They never moved on to newer and beter things, because their vendors gave them backwards compatibility. Saved them lots of money by not having to upgrade!
Pretty soon, my group's productivity is back down to the same level as the rest of big-old-slow corp. With no reason to keep us around, they close my group down. Woohoo backwards compatibility saves they day!
By the perception of illusion, we experience reality
Tell that to a Gentoo user!
I have looked at Gentoo, and I'm mostly a FreeBSD user myself. I do compile virtually everything myself, and for me that is perfectly acceptable, but I am not so stupid to believe that what works for me will work for everyone. Demanding that every user knows enough about software development to compile everything themselves is a good show of complete lack of realism.
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
Both those approaches are sometimes used and sometimes work, but mostly just add new crud. Sadly for MS, they can't avoid it without changing the industry in ways they don't want to change. Source compatibility is a much better solution technically - but it doesn't work when the majority of your ecosystem is mushware-only.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Even if you could just slap on a new library and recompile it against the new lib, which doesn't work more often than not, that's not even the point.
Companies are, first and foremost, consumers. They don't want to recompile, they even complain if you want them to make a few setup tweaks or even check some options. The maximum you may require from them is up to one minute of work to get something up and running, and that minute should include explaining to a dummy what is expected from them.
If it isn't "unwrap and plug in", they already shun it. Recompiling sounds like something they have to hire an expert for and, those in business themselves will know, in our world, the most expensive thing for a company is work force.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
If so-called professional programmers choose to ignore them, the risk should be on the programmers and the companies who hire them. Implementing "within the lines" should be a key part of any programmer's ethics and skills, especially when they're getting paid.
Of course, one would wish that Microsoft would actually follow existing standards, instead of making their own standards for things like OS APIs... But that does not excuse those who ignore the published public API documentation.
dave
Have you ever tried running actual windows based programs on later versions of the OS?
It was not a fun experience for me.
Most corp data is accessable or importable in standard formats.
The problem is not the data, it is the time and effort required for a rewrite.
Why spend countless man hours to rewrite a program that works fine just becasue it is not in the most recent wiz-bang language.
Most organizaitions are trying to make money and have better things for their programmers to work on then rewiting the custom HR system or other such nonsense that doesnt generate revenue.
Compare Solaris's backwards compatibility with Windows...very different views of the same subject.
I've still got SUNOS 4 code ( from suppliers long since disappeared) running on Solaris 9.
Trying to that with Windows code is a real bother....might work and might not - more likely not.
Gotta give the devils their due here. I'm still running Paradox 3.5 for DOS, MultiMate Advantage, and even dBase IV under XP.
(Unlike with windows) there is not only one distribution of Linux, so different distributions have different mindsets. With distributions like Ubuntu nobody has to recompile anything himself/herself.
However my point still holds: having the source available is much better than any sort of bug-for-bug binary backwards compatibility. Whether you compile it yourself (like the Gentoo or even Slackware users love to), or the distribution provides precompiled binaries for everything is just a matter of choice. A matter of freedom. And this is something Windows will never offer.
If you don't fail at least 90 percent of the time, you're not aiming high enough. (Alan Kay)
With .NET, forward migration is easy, because you can easily compile your old apps on the new framework with few changes.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
Raymond often talks about new OS version having to keep application relying on hacks working. People don't care if game is doing crazy crap internally to determine something (which could have easily been queried with a documented API call)... they care that they upgraded to Windows XP and *it* broke their game.
Without backwards compatibility, however incomplete, different versions of Windows would be different platforms. Which would compete with each other, and especially with new releases of apps and OS. And interfere with Microsoft's claims to represent 90% of installed computers/users/whatever. Which claims are the main factor when most people decide whether to buy/install/develop MS apps.
Backwards compatibility, even if not extensive enough to make all installed MS hosts (including WinCE) into a single platform for the largest imagined application scale economies, is enough to create the illusion of those benefits. Which keeps people buying and building MS at the large scales which actually do deliver those lesser, but still extremely competitive, scale economies.
--
make install -not war
However my point still holds: having the source available is much better than any sort of bug-for-bug binary backwards compatibility.
That really depends, for someone who simply lacks the technical knowledge, a system built on 'bug-for-bug binary backwards compatibility' will actually do the job of running older applications, a system with source available won't.
That said, when the backward compatibility breaks, chances on fixing the situation will be a lot better when source is available.
What is better for you really depends on what is usable to you.
Whether you compile it yourself (like the Gentoo or even Slackware users love to), or the distribution provides precompiled binaries for everything is just a matter of choice. A matter of freedom. And this is something Windows will never offer.
That is all nice and well, but it does not help people who are not knowledgable about software development, whereas a system that is 'bug-for-bug backward compatible' will help such people.
And yes, I am aware that it also has a price, and I am personally not willing to pay that price, hence I use a different system where I can indeed fix things when needed without depending on others, matter of fact is that I have the knowledge to actually make use of that feature.
Migrating from an old Compaq server running Debian Sarge to a new HP server running Ubuntu Dapper Drake.
No problems with any of the infrastructure apps (DNS, DHCP, NTP, etc).
Next I'll be adding the functions from an old Red Hat box. That includes Plone and such. I've already tested in on a different machine and there are no problems.
I keep hearing about "problems" but I'm not seeing any and I can give specifics on what apps we're running and how easy it was to upgrade/migrate them.
Meanwhile, we're still running WinNT 4.0 because we have an insurance app that requires a DOS environment and Microsoft broke that between WinNT 4.0 and Win2K (doesn't work in WinXP or Win2K3 either).
A friend of mine has a very nice mexican restaurant and the software for the cash register is DOS based. It looks good (even uses a touch screen), it works - why would he ever invest 10000 Euros to buy a new one (that much because it's special software, you can't buy cash register software for restaurants at CompUSA, and he has to buy new hardware too - even if the new stuff would run on his machine, the companies who sell it to him and support him require this to lower their own support load by refusing to support any hardware/software combinations but their own ones).
:-) ), b) I'm an IT guy, had quit my employee life only half a year before starting this business together with a friend, c) we just started so everything was new. But reality is, you're busy all day and thinking about which patch, what software, or what nice piece of hardware one could buy for ones business is the LAST thing one wants to worry about in such a situation! There just is no time to deal with IT, and little money ((esp. onsite) IT support is *very* expensive if you have a question that cannot be answered by the outsourced call center in India), and if there's money left one can think of many more important investments than IT. Do you know how expensive even very basic equipment used for making brochures or booklets is? (tip: don't EVER buy plastic, such machines must be STEEL or they'll fall apart - paper is very tough, hard to process, you won't belive it!)
/. guys keep talking about huge data centers and big businesses with a big budget and an IT department. Do you have any idea how hard any update is for the much larger part of the economy, the SMALL businesses? They cannot afford to higher someone, they cannot afford to spend much time on their software (even I need more than a full day to finish setting up a new PC, I just got a new Dell, and installing all my software and setting up my work environment is SUCH a pain!)
I myself still own half of a (German) MBE (Mailboxes Etc.) store (95% business customers, 75% digital printing), and the only reasons our PCs were up to date were a) we did a lot of digital printing and some design, and Adobe Creative Suite CS(2) needs LOTS of resources (but it's great software - proprietary, bloated, etc. - but I like it anyway except for the price
There are many, many SMALL businesses like that. You
You (in general, majority here) don't like large corporations or at least treat them with a LOT of suspicion, but all I ever read here is about the big companies.
DOS support isn't extremely hard, and it isn't something Windows is exceptional at. I know Windows users who are now stuck using Dosbox to run their oldest games, just like us Linux users.
If you really want to demonstrate a Linux distribution having problems with backwards compatibility, I'd point out the removal of LinuxThreads support when Fedora Core 5 went NPTL-only. Damn Red Hat, I want to play SimCity 3000 again! (Oh, yeah, and it broke a bunch of old versions of non-entertainment software, too.)
Remember, Windows isn't done until Lotus won't run!
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
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.
But they take an OS with less than 70% seriously?
This is just more Vista bullshit, much like the "XP is solid" nonsense that came before the launch of XP. Everyone knows that the upgrade train forces everything in it's chain. Just a few days ago Ars Technica did a study on how sucky in place upgrades to Vista were. As a normal free software user, I almost never see version and upgrade problems with data. As a user of lots of old equipment and new software, I know free software offers much better support. How anyone can declare M$ a winner in any kind of compatibility contest is beyond me.
Friends don't help friends install M$ junk.
...a non-coding standpoint. As a business we have a huge amount of data in the archives, in our case only from 91. One of our biggest issues is if we need to access that data we need the current platforms and application software to be backwards compatible. If the systems were not backwards compatible we would have to dedicate a/several computer/s and then up-load the old software to access the data. I suppose that we could use emulators. Bottom line is that it would be a huge pain for IT. In addition, it would be nice if anyone of the Project Managers can access the data from the server directly without worrying how to view it.
A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort.
Well played sir!
www.jmagar.com
-
Best in the industry? Please. I can still compile and run both MASM and Fortran software written in 1966 for a ancient UNIVAC 1108 mainframe on a modern Unisys Clearpath Dorado mainframe using the latest version of OS2200, and software compiled after the mid-70's can be run as is on the modern box without recompiling it at all.
Microsoft isn't even the best in the Intel world. Compare the level of DOS compatibility in Windows XP or Vista to that found in eComStation 1.2R, for example. Heck, compare the level of compatibility found in Windows 95 and/or NT 3.1 or NT 4 to eComStation. IBM wrote a virtual machine to handle DOS programs inside a true 32-bit architecture, and it will run all kinds of software that the VDMs in NT, Win2K, and XP can't dream of handling.
Microsoft has continuously placed a priority on customer migration to the next version of their native API over any support for legacy software, and their product lines have a long history of systematically phasing out older APIs. The "backwards compatibility" card was played to the hilt in the Windows 9x days in an attempt to explain that fact that Windows 9x was little more than a sophisticated-but-piecemeal 32-bit shell running on top of a copy of real DOS, while Microsoft's support for DOS software in its real 32-bit offerings has been pathetic.
You bought the MS party line hook line and sinker, but that *doesn't* make it reality.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Very good post, and very good points... BUT you forgot to mention that you can also run the exact same 27 year old binary the grandparent poster mentioned, under DosEmu, as well. ;)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
The analogy to your view would imply that just because I drive a car, I'm interested in doing the maintenance myself.
Why buy a car designed in 2001 with the 2007 paint scheme so I can recycle the tyres; when I can buy a 2007 car which comes with brand new tyres!
Who needs backwards compatibility. My Commodore 64 still runs all of my Commodore 64 programs. My XBox still plays all of my XBox games. My DOS games still run great under DOS 5.0 (6.2 and 6.22 were where MS started pushing bloatware over beneficial functionality).
I'm in favor of trimming some of the fat. If MS has a 3 version back support policy for the OS itself, why not have a 3 version back support policy for any features. After 3 versions, you may or may not get to keep your API. They do it with other areas (for example, SQL Server has not guarantee that certain features will be supported in the next release and MS recommends that you update your code).
Layne
His point is that you need to use a DOS emulator to run it. You could use an entire DOS operating system (e.g. FreeDOS) or a DOS emulator (e.g. DOSbox).
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
I can't run GPSS/H (a discrete-event simulation program for DOS) under XP (using a cmd.exe window). It worked in all versions of Windows (including Win2K) up until XP. I have a few other DOS programs that no longer work in XP. So I'm not at all impressed with Windows' backward compatibility.
Uh, the Linux kernel is only 15 years old. I don't think it's very good at being backwards-compatible with nonexistent programs (you can't compile a binary for Linux circa 1979 if it didn't exist).
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
Is it better to have 50 different servers with different operating systems, different software configurations, different connections etc, or just replace a significant fraction with largely identical systems when increased load or hardware failure necessitates upgrading?
Can you be Even More Awesome?!
This article has given me a bit of satisfaction. I am an IT manager for a small company that uses 1993 code that has had tweaks here and there, but is largely unchanged. My boss likes it because the AS/400 has not been down in 13 years except when we want it to. Last year our main server for Terminal Services was down 9 times in 11 days!
I can also install and run Chips Challenge from a Windows 3.1 diskette on any Windows XP machine and run it no problem.
Even though this is /., I ran Linux for the first time last week when I tried out DSL. I guess I just don't see the big whoopdie doo.
That's great, if your C64 still works, and you have space for that many machine. In the business world, you typically want to have as few machines as possible (for space, power and administration cost reasons). If you need a new machine, either because the old machine is too slow or because it's broken, you don't want to have to buy new versions of your software (or new software, if the old code is no longer maintained) simply because your OS has dropped backwards compatibility.
I am TheRaven on Soylent News
Just like the old Beatles albums that proclaimed "John is dead" when played backwards, when you play the Windows CD backwards it says "Jobs is dead".
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
The Multicians had a set of rules that allowed them to do "continuous maintenance" on production systems without forcing everything to change at once.
The compatibility didn't last forever, but if you were an application developer, you really only need to do a QA run once a quarter to see if anything was in the process of changing, and schedule a fix for the next quarter. Your customers had a longer guarantee, probably a year or so.
The idea was a lot like relational database theory: you can always "add a column to the table" and you could use NULLs to mark an old column as not containing anything any more, although the actual technology was major- and minor-version-numbers, and was derived from some hardware-versioning research at MIT.
They still work: I used the same techniques in a Unix project, and never had to have a flag day, although Edsel and I were changeling the interface in question with wild abandon (;-))
--dave
davecb@spamcop.net
IANAP and IANASB (Programmer, Successful Businessman), but I have what I hope isn't too stupid a question.
MS has for some time differentiated between home and Pro versions of their OSes, why not a Legacy & no-Legacy version? This doesn't sound (to me) to be so hard a concept, and everyone gets what they want. The defacto version would likely have to be Legacy (like on $500 Dells) but as people start to realize (because their kids/friends/whatever tell them so) the no-Legacy version is faster/better/whatever, people will wean to it. Hospitals, etc that will more-or-less always need legacy support can continue to buy that version, but in 5-10 years MS can charge twice (or more) as much for it since it will by then be a niche OS. Then we get an OS that isn't bogged down, the instances where it is needed are covered . . .
Does this not make good business sense for MS? Surely they have enough programmers that supporting two completely different versions of their OS would not be a hardship.
"If you have nothing to hide, you have nothing to fear." - Every fascist, ever
I still have a copy of VP Planner, a DOS spreadsheet program, on a 720KB floppy disk. That was the first spreadsheet I ever used, back in 1990 (right before the company that made it got sued for copying Lotus 1-2-3's interface, IIRC).
...having said this exact thing only a couple days ago even though I was totally oblivious to this blog post that obviously predates my comment (see http://linux.slashdot.org/comments.pl?sid=205851&c id=16794030), what a coincidence indeed :-)
I don't want to become a programmer just to use my computer. (90% of office workers speaking, I.T. specific roles excluded)
Did anyone ever think that I don't want to become a programmer just to run my network?
Why is it assumed that these two talents naturally just go hand-in-hand? I can write some code, mostly scripts, SQL queries and so forth, but know not one thing about C or C++. What I can do is develop an enterprise sized network, with hardware and software requirements competing for my $5,000,000 budget.
I can't write even a simple perl script.
Why must it be assumed that IT guys can code. Not all of us can, and a lot of us don't want to (if I did, I'd be working on the Linux Kernel or any other F/OSS project that interests me).
Get your Unix fortune now!
I don't see backward compatability as that big of a deal, for the most part it's a Shell creating a virtual machine. The O/S has actually become preloader software, the only change is it's interface back to the main system. Anyone wishing to use extremely old software should know of the inherent bugs/security flaws in that sofware, and that a new O/S isn't going to fix that. Would someone be so cheap that they replaced and OLD O/S with a brand new one and then try to continue too use Legacy Apps? Maybe only government and some college grad IT Managers...
Ad eundum quo nemo ante iit!
I'm not sure Visicalc is that good a test. I just downloaded and ran Visicalc in DOSBox on OS X/PowerPC.
I am TheRaven on Soylent News
And that with fifteen years' experience developing environmental models on Solaris, IRIX, AIX, HPUX, Linux...
fwiw
"My opinions are my own, and I've got *lots* of them!"
While I'll fully aggree with your points about the common user, I'd argue that IMHO it's not that much different for programmers and generally those in IT roles. Sure, for a programmer it's a lot less intimidating and a lot less "rocket science", but that doesn't mean he/she will automatically enjoy it.
Speaking as a programmer, the interesting and challenging part is the _programming_ part. The tweaking of algorithms, the thrill of learning some new technique, etc. That's the fun part. The compiling itself is _not_ the exciting part. Sitting and watching Joe's Own Toy Program (TM) compile is about as exciting and watching paint dry. Tracking down the dependencies for it is even less exciting.
In fact, I'll even go ahead and say that anyone whose great feat was compiling some 3rd party program, probably isn't really a programmer to start with. There are a ton of people who just like to pretend they're oh-so l33t because they can run someone else's build script. Maybe they even configured (through the nice supplied GUI) and compiled (by running the commands supplied in the readme) a _kernel_. Wow, that makes them sooo great computing gurus. Not. That's to programming what script-kiddies are to real security experts. A sad joke.
And even as programming goes, the fun is doing the things _I_ want to do, learning the things that _I_ find interesting at the moment. Maybe I'll toy with this great new algorithm or language I just heard about, or maybe I'll mod a game just for the sake of seeing if I can get to the ballistics code, or whatever. Whatever tempts me at the moment. But that's a personal, subjective and transient thing. What tempts me tonight might be (and usually _is_) a whole other thing than whatever program Tom couldn't be arsed to finish, or Dick couldn't be arsed to test, or Harry couldn't be arsed to port. I want to do _my_ stuff, not debug Tom, Dick and Harry's programs just because they happen to be OSS and on my computer.
Basically just like a literature buff might choose to spend the evening reading the novel of _his_ choosing instead of coming over to help the neighbour's kid finish a school essay about War And Peace. Sure, he certainly is qualified to help that kid, but it's not necessarily what he'd choose to spend the evening with.
In the end what I'm saying is that what I want from a computer is no different from what Jack Random and Jane Average want. I want it to just work. Whatever I choose to do with it, whether it's programming my own toy app or watching a DVD or playing a game, I _don't_ want to compile the IDE/media-player/game/whatever first, and that goes double for pointless track-the-dependencies games. If I chose to do X tonight, then anything else that gets in between me and X (like having to first compile some other stuff) is just a waste of my time.
A polar bear is a cartesian bear after a coordinate transform.
Mod legitimate questions down!!!
When Tiger came out, I've seen lots of applications broken and... lots updated. Now developers are moving to Universal Binaries. I'm surprised that Apple gets away with this, but as long as they do - IMHO it's a good thing: almost nobody uses unmaintained software.
Microsoft is the greatest marketing company that every existed. Microsoft products DON"T just work. I'm so tired hearing that BS. I waste so much time (and I know I'm not the only one) trying to resolve endless problems were they don't just work. Not only that but sometimes they mysteriously just stop working for no apparent reason after they were working. Add to that the problem that it is nearly impossible to trouble shoot problems since little or no information is provided to the user. With Unix/Linux if there is an NFS or ssh issue I just turn up the logging level. With Windows it's reboot while sacrificing a chicken. I have 2 Linux servers sitting here right now that I set up and have worked flawlessly, one for over 3 years with only maybe a dozen reboots over that period. I support Unix servers that haven't been rebooted in years.
As to Linux on the desktop I would rather have some training expense up front then spend forever fighting viruses, anti-virus software, malware, anti-malware software and the just plan mysterious Windows problems that occur on Windows desktops.
Windows updates and upgrades not breaking things is crap also. The list of applications that were broke by WinXP SP2 was long and prestigious and included several of Microsoft's more prominent applications. And although they have gotten better I still tremble when Windows updates occur from past experiences of complete system failures on reboot after an update.
I have 20 years experience in this industry on both Windows and Unix/Linux. I've written device drivers and developed realtime embedded systems along with gui apps in probable a dozen languages. I've hack around with kernel modules on occasion. If someone with my level of experience can't diagnose problems that occur in Windows claiming that it just works is complete BS. Only a couple times have I encountered problems in Unix/Linux that I couldn't find a root cause for and in those cases it was more of a problem with time and money rather then a lack of information to find a root cause. With Windows you contact their support and the first step in resolution is reboot. If that fixes the problem there is no way to continue to a root cause.
Who is John Galt?
People always complain about how Microsoft should be like Apple and throw everything old into the trash every few years and start a new. Its actually the reason Apple will NEVER be used in a corporate setting and why Microsoft will still be making tons of money 20 years from now.
I'd put my money on Sun being better and in a more complex space also. There stuff is used extensively in places like telecom. I could just imagine running any kind of phone switch on Windows.
Who is John Galt?
You got it all back-OSwards!
Assuming a typical linux distro with the typical set of apps - if you were to compile in all the dependencies, how much extra space are we really talking about? Ten MB? Ten GB? One hundred GB?
I could live with 10GB of space used up for dependencies if it means less headaches. At around $1/GB, that's a very small price to pay for peace.
Spoon not. Fork, or fork not. There is no spoon.
FreeBSD (and, I believe, Linux too) can run applications from a variety of legacy UNIX programs so, assuming you have compatible hardware, you can run applications that pre-date the operating system quite easily.
I am TheRaven on Soylent News
The "command environment" that Microsoft implemented on WinNT doesn't handle timing well. Virtual machines want to time/slice the processor. Using the DOS app in a virtual machine means it runs so slow that it has other issues.
Yep, we've even tried DOS-box.
The only real solution at the moment is to keep a stack of old hardware around so we can keep this app alive until the data is finally done. And that's a long time in the insurance business.
Best in the business?
No. I worked in the group at SUN that offered the "application guarantee". As an ISP, run your application through a standard tool -- if it passes the ABI, then its SUNs problem if it doesn't work on future OS releases.
Solaris wins. As a server OS, you arguably can't get better.
And when it's GPL'd, *and* still SUN supported, it'll be better. POSIX and other standards are not to be trifled with...
Ratboy.
Just another "Cubible(sic) Joe" 2 17 3061
Yeah... but I can show you a ton of *very* useful software that you just cannot use on Solaris when using only Sun tools (e.g. Boost). That's because Sun cannot bring their compiler up to snuff without breaking backwards compatibility. There's a tradeoff that one makes for the level of backwards compatibility. And those tradeoffs can cause more headaches than they are worth. Sun, IMO, has been on the wrong side of that equation for a very long time.
It's enough of a problem that we are in the process of switching over to GCC.
And to reinforce what two other posters have said, we are upgrading from SunOS 5.8 to 5.10 and are running into binary compatibility issues with Sun's own libraries.
the growth in cynicism and rebellion has not been without cause
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
Yes, yes, I've been endlessly corrected on the Solaris front - my apologies.
I'm one of the people who decries MS's need to maintain backwards compatibility -- but it's not the backwards compatibility that I decry, but rather the fact that they need to maintian compatibility with a horribly mis-designed single-user system that is rife with land-mines originally meant to trip up their competition.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
It was Paul...
http://en.wikipedia.org/wiki/Paul_is_dead
[UID-HeinzIntel]
Linux falls flat on its face with backwards compatibility if you look at commercial, closed software. In an ideal world, everything would be open source enough that you could recompile it and have no problems. But in our non-ideal world, you've got stuff like Loki games and 3-5 year old commercial apps that simply will not run because of binary compatibility issues, unmaintained libraries, etc.
:)
Perhaps someone should make an emulation layer a la Mac OS Classic? Or a la Wine? Then we could run our old Linux apps with LINE - Line Is Not an Emulator.
"Wow, you're like some kind of superhero able to ward off happiness and success at every turn."
-- Ryan Stiles
People, please understand... the Linux development effort is not for the satisfaction of corporations or IT Offices. They're not paid for contributing to the kernel, but just do it for the hell of it. There's no metric there except experimentation, taste and beauty. If some company decides to outsource some of its code to the community to share the maintenance cost that's fine; if another one decides to give corporate support to it through a contract that's fine too. But don't blame Linux for not behaving like HP-UX or Windows, it's not the same thing, as far as the vanilla kernel is concerned. If you need backwards compat, 24/7 or enterprise hardware support call an Enterprise Linux provider and ask them to do all the necessary backporting, testing and life-cycle management necessary (and pay for it... there's no free lunch my friends. You thought you managed to screw those damn hippes again! ;-) )
e
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
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 ]
Why is Linux being lambasted here for poor backwards compatibility?
I've heard stories of running code from linux 1.0 on linux 2.0, and I have recently used software compiled for linux 2.2 on 2.6. So why is the backwards incompatibility of GlibC and GCC and other common libraries whose APIs have changed as they mature suddenly the fault of linux?
Blame the GNU guys for GlibC's versioning scheme if you really must complain. Blame them for the change in binutils' ABI changes in recent versions.
After all, this is why most linux distros have libstdc++.5 (GCC 3.3 and prior) installed next to libstdc++.6 (GCC 3.4 and later)!
Anyway, even somewhat ancient games that use OSS, an old MesaGL build, and were statically linked and compiled with GCC 2.95 still run. So what's the problem?
grey wolf
LET FORTRAN DIE!
Well, in-so-far as linux is like a kid with worms... always squirming and shifting, never settling in one position for more than a moment. I mean, I love linux, and I understand why the developers want the code to be as good as possible, but there comes a point when you need to say "enough is enough", set a standard in concrete, move on and stop moving the goddam target.
Ok, from the original article Mr. Chen posted he mentioned nine thousand scripts in one organization.
.NET. Granted there is a huge jump in techie know-how going from DDE to OLE/COM/ACTIVEX, the .NET infrastructure follows the same programmer methodologies/lifestyle as OLE/COM/ACTIVEX. Binary versioning, backward binary compatibility, forward binary compatibility as part of these. Key to all of this is to put a lot of thinking behind the interface specification. I've met a lot of developers that love to develop interface specs that have lots of parameters which eventually leads to trouble precisely because somebody wasn't thinking straight with the first version of the spec. In order to have backward compatibility, the new version has to have a mechanism to expose not only the newer services but also the older services. It is true that the new application might have the older services names call the newer services internally, the truth remains that the behaviour has changed because the code inside the new application isn't necessarily the same code and same quality as the original version.
That said, why did he decide to put the blame outright on OS versions. The keyword here is "scripts" which seems to imply an interpreted script engine somewhere. The script interpreter is either part of the shell interpreter for [place any windows OS version here]. If something broke, blame could be placed at any level: script interpreter-shell-level, application(s) level or OS-level.
Now if we change the meaning of "script" to visual basic for applications, here is where we see interesting changes.
Visual Basic for Applications implies the entire infrastructure below it permitting it to do reuse of existing components. That interapplication glue was previously called "DDE", then OLE/COM/ACTIVEX, and more recently
Going back to scripts, it doesn't matter if the script is dos batch, wsh, VBA, perl, bash, python or whatever, if the service specs suck and the coder has no comprehension of OOA&D, the script will run into trouble eventually. That has nothing to do with OS Versions or OS Level stuff. It has all to do with component reuse on any OS. Linux does it better because usually if you simply recompile using the latest sources of everything, it usually fixes it. If there are fixes to be done in Linux, like in Windows, there will be effort needed but I am betting there will be less effort needed on the Linux maintenance because all the source is readily available thus resulting in lower TCO(total cost of ownership) for the company using Linux. I should mention the more timely updates Linux repositories provide. This is the huge part of the synergy Linux has and [Windows version here] will never have.
Suggestions to the company:
1)Keep the same coder no matter unlikeable you may think the coder is. Coders usually care about their work and want to do their best.
2)Let the coder make the decisions concerning the operating system. Any coder worth his money will try new things and new OS's. Eventually he will discover GNU and choose it over closed-source for obvious reasons.
3)If the script interpreter doesn't run in linux, it's because you haven't got the source code for it, which makes it impossible to maintain which means the company is better off getting rid of the crap and choosing a company that does not lock it into a corner. If you have the source code under linux however, the odd of the application being maintainable in the long run are higher than maintaining on a windows operating system because linux runs on more kinds of hardware than windows ever will. APPLE OSX might be cool, but making it closed-source and constrained with its licensing will kill it eventually which is Microsoft Vista's fate in my humble opinion. Everything being mentioned in the media recently about Microsoft making deals with some Linux providers is just "Smoke and Mirrors". As a result all developers should be concerned and remain vigilant about this. Any co
Its is easy to find root cause on Unix/Linux but nearly impossible on Windows, one of the reasons is Windows has no root.
Convert the data.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
In every non-trivial program there is at least one bug.
"Beware of he who would deny you access to information, for in his heart he dreams himself your master."
I've had this thought on my mind for a couple of days now. While it is apparent that backwards compatibility is extremely important to encourage people to upgrade to your latest and greatest (and therefore gain the licensing monies that come from that.) You also need to continue to evolve the software and make it more capable. Look at the benefits of not having a 100% stable ABI the Linux kernel improves at an astonishing rate and stuff like KDE and Gnome andvance by leaps and bounds with every release. On the other hand you have an untold number of machines that have been using Microsoft's HTML dlls and now that IE7 is out programs are breaking by the scores. Personally I don't know why they couldn't install IE7 into different files(for example if IE6 dlls are MSHTML.dll, make IE7 MSHTML7.dll (versioning, hilarious thought right?) and just remove the shortcuts to the old IE6 crap so people can move forward with a new browser and corporations can continue to upgrade without breaking all of their legacy crap. I agree that IE6 (and still IE in general, though getting better) NEEDS TO GO. Dropping a product and all of its capabilities without going through a deprecation cycle (Like GLIBC and such) is completely batshit insane.
Your distribution has a package management system and other people do it for you but if you wish to play with things too new to be available that way there is a learning curve.
Corporations, government, and other large organizations put together a matrix of hardware, O/S, third-party products, and in-house software to build a production system. Once it's been tested and certified for production, you do not touch it except to apply critical security patches.
When you buy a new box for upgraded OS and products, you go through the effort again.
Even if the APIs are 100% compatible on an OS upgrade, you still need to recertify the combination of products.
Only nickle-and-diming PHBs that understand a bit of IT think backwards compatability matters; those who are completely clueless leave it up to the techs. The other segment of people who care about compatability are those who have a healthy chunk of change invested in office automation, games, and other software who buy a new PC with a new OS.
While I sympathize with the fact that an OS upgrade usually means an "upgrade everything" cost, business realizes that, and factors it in to the decision whether and when to upgrade.
I do not fail; I succeed at finding out what does not work.
My old COBOL programs happily work on FedoraCore 6 (vanilla kernel 2.6.18).
We moved them from AT&T SysV R3 > SCO OS5 > RH7.2 > RH8 > FC3
I have never seen anything other than trivial applications that work from release to release of microsoft windows. Even the version of M$ paint from 3.1 would not work on windows95. The only backwards compatibility Microsoft has kept, is in the backend where it saved THEM work/money, and caused everyone else pain.
Applications are firmly tied up to OSes.
You rarely, if ever, install an application in a new OS which was designed for an old one.
And I am talking about Fortune 500 companies all around the world, which is where I have been working for the last 15 years.
In smaller companies you may do so, and as long as the application provider tells you it should work, you should be on the clear, but notice how the application is the one that dirves the adoption of the OS.
IANAL but write like a drunk one.
And then you are in your own. No patches, no fixes. No nothing.
With Linux you can hire support or fix problems yourelf (as in hiring developers to get you out of a hole).
IANAL but write like a drunk one.
I want to be IT manager there.
IANAL but write like a drunk one.
They should run. As simple as that.
To put the burden suqarely on the developers for backwards compatibility is quite something.
What should happen is that backwards compatibility should not be used as a selling point for any OS because it is completely impossible to guarantee it.
IANAL but write like a drunk one.
Just use the standard tools to install software.
If you have to compile stuff you machine is classed as a devleopment/QA one, in which case things are guranteed to brake.
Get yourself a virtual machine were to test your compilations and stop whining for bunnies sakes.
IANAL but write like a drunk one.
This is a fairly good point.
I was talking to a coworker today about running old DOS applications, for people that don't want to or can't learn new software, but have new hardware.
Rather than try to install WordPerfect for DOS on top of an actual modern Windows install, I think it's a whole lot easier these days to install a virtualization system on top of the host OS, and run FreeDOS (or actual MS-DOS, if you can find a copy) on that, to support the old applications. As long as your VM system emulates the 'bare metal' and isn't aimed at only supporting one type of client OS, then this is pretty simple to set up.
I think actually the next time someone in my family complains about how much harder computers are to use today versus ten years ago, I'm going to set up MS-DOS in a VM (I still have a whole set of 3.5" installation floppies somewhere), fullscreen it, and see what they think. Somehow I think perhaps they're viewing the past through rose-colored glasses...but who knows. Maybe they'll prefer the old way.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I for one haven't found any useful applications I can run prior to mid 90's.
How about Air Traffic Control?
There are so many comments in this thread with the modern viewpoint that anything older than last week is unimportant. Businesses have huge amounts of old data that can't just be invalidated at a whim because it may need to be accessed (legal reporting requirements), and hardware was bought on 20 or 30 year amortization (by law at the time in the telecom industry), so change is a big deal. Heck, even Microsoft's change of "time" from 32 to 64 bits screws up all kinds of compatibility with existing databases and any backups thereof.
Pure and simple, Microsoft has protected their market share by remaining backwards compatible, and will continue to do so for that reason only.
When windows 95 came out, and Microsoft was competing with 3.x versus Os2/Warp, 95 was released without one critical piece of backwards compatibility.
Although old 16 bit programs were given twiddled names from file requestors (needed, as they needed to work with short file names), end users were shown ugly twiddles all over the place.
This effectively meant that older programs were broken, and needed to be replaced with new ones.
New ones that didn't run on the competing OS's.
Suddenly, the market share of microsoft increased -- leveraging the "new computers come with us by default" / "People have to buy and install our competition" with "New apps no longer work with our competition".
Microsoft keeps or breaks backwards compatibility based on "What's best for us, given the current environment?".
Don't forget -- XP changed the driver model and broke a LOT of device drivers. Still think they have backwards compatibility as a big thing?
There is aways the option to run a virtual machine with the outdated API installed. In fact there is aways the possibility of selling those compatibility APIs so that those business who depend on those and do not wish to maintain an old machine. Those could even be a set of DLLs that would run in a different environment.
[]'s Victor Bogado da Silva Lins
^[:wq