From strictly an engineering perspective, I stopped developing for FB a few years ago because their API was like quicksand that you stepped in by chance because your treasure map was so bad. It would change every week, it was buggy, poor or no documentation, different standards coming and going every week with no signal as to which one FB would settle on, and no warning when their changes would break things. Maybe things have improved since then, but I left that experience so scarred that I'm never touching their dev tools again.
Maybe Windows isn't that pleasant to work on, but not in any of the ways that he was describing. Windows has always had very stable APIs. The basic Win32 APIs have remained stable and constant for an insanely long period of time; there was plenty of churn in what was the recommended way to write an app (Win32 -> MFC -> .NET), but those are essentially higher levels and it seems that they've remained stable as well.
It seems like Windows RT is the first time they've actually broken backwards binary compatibility isn't it?
It seems like Windows RT is the first time they've actually broken backwards binary compatibility isn't it?
Very much not true. Early on, "DOS isn't done until Lotus won't run." They pulled the same trick several times against competitors, for instance Microsoft Word took dominance with Windows 95 because there was a period of 9 months where WordPress was not available on the new OS while Microsoft Word was.
This was one of the issues in Novell's 2004 lawsuit against Microsoft for anti-competitive behavior. The last I heard was an appeal filed late last year, see http://www.groklaw.net/article.php?story=20121123221716522 for details. I do not think that the appeal has been decided yet.
There have been other, less nefarious, sources of breakage. For instance at one point Microsoft changed malloc() to try to assign recently deallocated memory if possible. The purpose is laudable - it is to push developers to notice and fix memory bugs. However, it naturally caused many programs that had been working to quickly crash. (Previously they would have run for much longer before crashing - long enough to be useful, but quickly enough to contribute to the perception that Microsoft software was buggy.)
Therefore Microsoft made a list of important programs that it knew would crash, and for those programs only gave them the old behavior. Many small companies did not make the list, and the result is that their programs wouldn't run after that upgrade.
Microsoft's behavior here was defensible (in fact I like it), but it was a deliberate incompatibility.
Therefore Microsoft made a list of important programs that it knew would crash, and for those programs only gave them the old behavior. Many small companies did not make the list, and the result is that their programs wouldn't run after that upgrade.
In fact, I just ran across an old fax from one of the Windows 95 devs, telling me how they planned to patch Windows to work around a bug in my middleware library that didn't show up until people started running their apps in Windows 95 DOS boxes, and asking for my opinion.
That was a far cry from the "DOS isn't done 'til Lotus won't run" behavior that the company was previously known for, and also a long way from their later behavior with Vista ("They bought their tickets, let them crash.")
I've written Windows software in C++ for more than 10 years, and I've compiled as recently as 6 months ago software that was written in the early 1990's, and that would compile and run unmodified on today's OS's. Show me one platform (or library even) that has that sort of backward compatibility.
There is a lot to be said about developing for Windows, but not being backwards compatible for sure is not one of those things.
I've written Windows software in C++ for more than 10 years, and I've compiled as recently as 6 months ago software that was written in the early 1990's, and that would compile and run unmodified on today's OS's. Show me one platform (or library even) that has that sort of backward compatibility.
Challenge accepted.
IBM shipped the first iteration of the System/360 in 1966. They have maintained, with minor caveats, backwards application compatibility with that version to the present across their various mainframe lines.
As an example of such a caveat, in 1995 the AS400 line underwent the 48-bit to 64-bit transition. If your executable was "observable", meaning it had debugging information, the first time you ran in 64-bit mode IBM would recompile it under the hood and your software would then run in 64-bit mode. If you had no source and no debugging information in your executable, you were out of luck until you got a new executable. Most customers experienced no issues.
But..mainframes? Who uses those? A lot of people, it turns out. A 2005 estimate said that globally 90% of financial transactions ran through COBOL. There is no reason to believe that this figure is significantly reduced today. The core of most of that COBOL code is decades old, and the customers are locked to IBM's platform because nobody can afford the cost or risk of a rewrite. But machines need to be replaced. Therefore IBM's customers still collectively cough up an average of something like $1 billion/month on new mainframe hardware.
> Many small companies did not make the list, and the result is that their programs wouldn't run after that upgrade.
I've been developing a programmer’s editor for every version of Windows since 3.0 and can honestly say I never notice any of these issues with newer versions of Windows.
I can safely say the crashes I witnessed where all of my own making.
Windows RT didn't break any compatibility because Windows RT was built on the ARM hardware platform. Win32 was just a software platform on Intel's hardware platform and won't work on ARM's hardware.
I think I meant to write WinRT instead of Windows RT. My understanding is that Windows RT is the new ARM-based Windows OS, but WinRT is a new set of system calls which replace the old Win32 APIs. Am I mistaken in this?
