Microsoft puts a LOT of effort into application compatibility. They're very serious about it, and the fact that they fail at times is proof of how hard it is to maintain app compatibility when application developers are doing their best to sabotage you by using internal APIs and corrupting the heap.
Driver compatibility is less of an issue; older hardware becomes less common (and thus less of an issue) over time, and strictly adhering to kernel compatibility limits your ability to add new features to the kernel significantly.
That's true, but sadly they don't put as much effort into compatibility of development tools. Old code has to be ported to new versions of Visual Studio. Even just sticking with C++, I ran into issues with winioctl.h and unicode fstreams requiring different code for different versions of VC++. I imagine other people may have a longer list.
That's sort of the flip side of the same coin. Associating specific runtime versions with apps at build time reduces the bug surface. They don't have to worry about breaking last year's apps with this year's changes to the standard libraries.
And yes, I agree it sucks. But that's the world of proprietary software. I think MS has done this about as well as anyone could.
Unfortunately, it took them quite a while to have an actually vaguely conforming C++ implementation, and there are still issues (there was a nice example on Hacker News a while back involving some stl method being dramatically slower than both its equivalent in other major implementations, and a near-equivalent MS-specific method), which may explain some of that.
Comments
Microsoft puts a LOT of effort into application compatibility. They're very serious about it, and the fact that they fail at times is proof of how hard it is to maintain app compatibility when application developers are doing their best to sabotage you by using internal APIs and corrupting the heap.
Driver compatibility is less of an issue; older hardware becomes less common (and thus less of an issue) over time, and strictly adhering to kernel compatibility limits your ability to add new features to the kernel significantly.
That's true, but sadly they don't put as much effort into compatibility of development tools. Old code has to be ported to new versions of Visual Studio. Even just sticking with C++, I ran into issues with winioctl.h and unicode fstreams requiring different code for different versions of VC++. I imagine other people may have a longer list.
That's sort of the flip side of the same coin. Associating specific runtime versions with apps at build time reduces the bug surface. They don't have to worry about breaking last year's apps with this year's changes to the standard libraries.
And yes, I agree it sucks. But that's the world of proprietary software. I think MS has done this about as well as anyone could.
Unfortunately, it took them quite a while to have an actually vaguely conforming C++ implementation, and there are still issues (there was a nice example on Hacker News a while back involving some stl method being dramatically slower than both its equivalent in other major implementations, and a near-equivalent MS-specific method), which may explain some of that.