4 ms·

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

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?

signalsignal 13y ago
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.
- deleted 13y ago
  [deleted]
- bratsche 13y ago
  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?
  - signalsignal 13y ago
    Yes. The Windows-Intel platform is fully backwards compatible back to Windows 3.1 with 32-bit.
btilly 13y ago
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 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.
- millstone 13y ago
  Oh, how delightful a slip. Run, the Internet is rotting your brain! btilly surely meant WordPerfect, not WordPress.
  - btilly 13y ago
    Oops, you are right.
- jussij 13y ago
  > 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.
- roel_v 13y ago
  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.
  - btilly 13y ago
    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.

signalsignal 13y ago

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.

deleted 13y ago
[deleted]
bratsche 13y ago
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?
- signalsignal 13y ago
  Yes. The Windows-Intel platform is fully backwards compatible back to Windows 3.1 with 32-bit.

btilly 13y ago

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

millstone 13y ago
Oh, how delightful a slip. Run, the Internet is rotting your brain! btilly surely meant WordPerfect, not WordPress.
- btilly 13y ago
  Oops, you are right.
jussij 13y ago
> 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.
roel_v 13y ago
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.
- btilly 13y ago
  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.