POSIX rarely changes. They should start there and work backwards.
UNIX nearly died because vendors wouldn't allow interoperability. Don't let it happen again.
Look at Win32 - still works like it did back in '91 (with Win16).
POSIX rarely changes. They should start there and work backwards.
UNIX nearly died because vendors wouldn't allow interoperability. Don't let it happen again.
Look at Win32 - still works like it did back in '91 (with Win16).
http://www.joelonsoftware.com/articles/APIWar.html
That's a good overview of how much "Maintaining weird legacy bug-compatibility code" you need in an OS with any history whatsoever.
The reason it still works is that they thought about it properly to start with. There have been very few extensions. The main one being adjusting pointer sizes (which are hidden behind a typedef like LPSTR anyway so that is irrelevent).
And for the record I take anything Joel says with a pinch of salt. The guy is a trendy blog mouth piece.
http://blogs.msdn.com/oldnewthing/archive/2003/10/15/55296.a... http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.a...
Here's a quote:
This is just the tip of the iceberg with respect to application compatibility. I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95.
Granted, backwards ABI compatibility is a huge, complicated, thankless task for which you get no notice if you do the job perfectly. The ideal spot for the "break old programs" vs. "cripple new programs to avoid breaking old ones" dial is different for every project. Sometimes the right thing to do is keep the code base from degenerating into a pile of back-hacks. Sometimes it's all about bending over backwards to keep a long-gone vendor's bug from biting your end users.
I've dragged some stuff which we wrote for NT4, recompiled it with VC++ 2008 (plus spent some time frigging VS settings) and it just worked on Win2k8. The original binaries, even though they were compiled 12 years ago, still run on Win2k3 fine and past the test suite (!).