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?
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.
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.