Slashdot Mirror
When Do You Kiss Backwards Compatibility Goodbye?
Arandir asks: "Backwards compatibility is great for users. But it sucks for developers. After a while your normally sensible and readable code becomes a nightmare spaghetti tangle of conditions, macros and multiple reinventions of the wheel. Eventually you have to kiss off backwards compatibility as more trouble than it's worth. The question is, when? Should my code conform to POSIX.1 or Single UNIX 2? Should I expect the user to have a ISO Standard C++ compiler? What about those users with SunOS-4.1.4, Slackware-3.2, and FreeBSD-2.2?" This question is really kind of difficult to answer in the general sense. The best advice one can give, of course, is "when you can get away with it". Not much help, that, but the lost of backwards compatibility, like most complex decisions, depends on a lot of factors. The key factor in most developers eyes, of course, is the bottom line. Have many of you been faced with this decision? What logic did you use to come to your decision and what suggestions do you have for others who might find themself in this predicament?
I think I like Apple's backwards compatibility, but it's not making one app backwards compatible,
For instance, when they migrated to the PPC architecture, they made apps that ran on both platforms and older OSes, then capped development and froze the older version at whatever version number, then developed for newer machines. The rest of the apps followed, like AOL 2.7 is AOL's last 68k release, they just developed only for PPC since then, although apps like Opera still make a 68k version alongside a PPC version.
Of course, you need to know your users, Will they be satisfied with a frozen and version capped release, provided there are no bugs?
This is the story of my app, Kinkatta ( http://kinaktta.sourceforge.net/ ). It originally was a QT only app and only recently did it move over to utilizing KDE. But that in itself isn't exactly what this is about so I will talk about the more spisific case. From .25 to .91 today we have gone through I believe 4 different formats in which we save our settings, buddylists and so forth. In each of the changes we had to add some code to convert it over. The best solution we found is to know our users and make sure they know about us. What I mean about that is that we only support the previous settings format and make sure everyone uses it. Kinkatta's users are kept informated when a new release is out through a number of ways. We then keep that format for as long as it takes for us to be sure that 99% of the users are using that format. One of the nice things incorperated into kinkatta is the auto-check feature. On login it will goto the webpage and see if there is a new version and if there is then it will tell the user. This prompts them to stay up with the new releases much more then if the feature was not there (and yes you can disable it). Do to the gpl/lgpl nature of the app people will upgrade more often and are unlikly to stay with version 0.64.1 This is a true plus point for the open source. Because of it we havn't had to worry about users who don't want to pay the 29.95 for the new version.
Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
...... say 'fuck all' to backwards compatibility.
(put your head in the sand and mark me down as a troll if you want, but this is one of the HUGEST problems with Linux, especially Gnome)
Oddly enough, when Altavista first came online, I used it frequently for trying to resolve DLL conflicts. Probably more than I used it for anything else.
:)
Sad to think that I can now find just about anything on the internet, and it all started because I had to support Windows 3.x.
But it is nice to think that I was running Linux as my primary box in my office in 1995, using lynx to browse as I debugged my new Windows 95 installation on my other box.
Just food for thought for the younger admins out there: DLL hell was the largest part of my job at many sites. Believe it or not, it has gotten much better in recent years. Think of video drivers messing up fax software, network drivers killing the accounting package, and video conferencing software killing the spreadsheet program. As sick as it sounds, Win 9x is a dream to support by comparison.
4:30 in the morning, I must be getting delusional.
So you're claiming Microsoft is making a mistake by providing backwards compatibility for DOS, but "open source," whose primary operating systems are Linux and FreeBSD, both designed to be backwards-compatible with 1970s UNIX systems, are somehow not?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
First, I'm not sure if we're talking about code compatibility or user compatibility but I'll talk about code compatibility (who cares about users anyhow? :).
I've found that Java is a great lanaguage for making backwards compatibility easier. The main reason is that dynamic linking doesn't use cardinals or offsets. This means that I can fundamentally reprogram and entire class (even without using an interface) and still have a dependent program work fine with recompiling it. (Note: the only gotcha is finals, which are copied at compiliation to the dependent program - bah!).
Along with a couple of other things, such as using lots of interfaces and factories throughout the library, backward compatibility is hardly an issue at the code level.
Jason.
..I used my mouse to cut and paste copyrighted material. It is a circumvension device made by Microsoft. Can anybody say DMCA??
<^>_<(ô ô)>_<^>
I've never seen even a smallish-application sized piece of Java code that would run 100% on all, of what? three?, of Sun's supported platforms....there are always platform dependent bug fixing (albeit not nearly as much as with C++). But combine this fact with Java's general pokiness and memory-appetite, and I'm afraid I can't see it as tremendous improvement over the current situation with our multiple Unix branches -- and can you imagine running an OS coded as much as possible in Java?
Maybe in time Java will work -- but I couldn't seriously consider Java for any major software project in it's present state. I'd rather see more effort put into a more unified and standardized Unix environment.
That is exactly my point: With Linux you know there are a great many users (with all sorts of different hardware, purchasing capacity, applications for your system, etc...) and so you would probably do best with having as much backward compatibility as possible.
With a propietary corporate system, such as the ones I write, you can pretty much dictate when people will upgrade, and if there are old and incapable systems, you just buy new machines. Much different than the open source/commercial software philosophy.
There's no way that you can satisfy all of your users
Well, system requirements much more broad than just "how much backward compatibility to have."
I would probably do what Linus does: Just focus on the very core and let someone else try to make everyone happy!
The API has barely changed in the last 25 years. A friend of mine has an application that's been running unchanged since the 1970s. It has contined to work across generations of hardware. And it's in assembler.
They had the advantage that their OS was decades ahead of its time. UNIVAC had symmetrical multiprocessing with threads in a protected mode environment thirty years ago.. And threads were designed in, not bolted on like UNIX.
"Ever noticed how the Win9x series is full of 16-bit user interface code"
...
Windows95 design team had clear objectives:
1. We need OS with protected memory etc
2. It MUST run 99% apps from Win 3.11
The only way to accomplish that was to retain tons of old 16 bit code and wrap it around with 32 bit stuff. Windows 95 is actually one of the most amazing pieces of software ever written.
Consider the fact that average RH has problem running most apps written mere year before that particular version was released.
"Or how only half of the NT kernel objects are supported under Win9x"
That is genuinely MS fault. They had communication problems between NT and Win 95 teams.