A recent
Slashdot article comment
wondered how Windows Vista managed to break existing applications,
despite Microsoft having complete control over the platform.
Specifically, the comment's author
writes.
Windows is the least standards compliant OS in the world [that is in current production], and YET they can't even keep their own software working with it. That is, they hold all of the cards and still can't make a play. That speaks volumes as to the quality of the shite software they put out.
When something like OpenOffice breaks in Fedora, you could say, well it's not Fedora's fault, they're aiming at UNIX/Linux standards by using industry standard libraries [X11, motif, glibc, etc, etc, etc], and the software just didn't work. But when people write for the proprietary Windows libraries and then Vista goes and breaks it all, that's just amazingly shotty engineering.
I beg to differ.
Applications break when moving from Windows XP to Windows Vista,
exactly because Windows is not standards-compliant.
A lack of a third-party controlled standards base allows Microsoft
to change the API as often as it likes, often within the lifetime of a release.
This gives Microsoft the short-term luxury of releasing shoddy interfaces,
by knowing it can improve them incrementally.
(Try to find how many ways exist to find the width of a text block.)
Naturally, such interfaces are very difficult to keep backward-compatible.
A lack of a neutral standards base means that the API is often lacking
functionality required for a specific task, since the API simply consists
of what Microsoft thought developers would require.
Missing API elements make developers use undocumented features,
borderline functionality, and workarounds.
Again, such applications are anything but portable.
A lack of a precisely defined standard means that there's no way to verify
the standards compliance of an application.
For example, all POSIX interface functions list precisely all the error
conditions they may encounter (the errno values).
One can verify that a critical application tests for those conditions
and behaves accordingly.
This is not the case for Windows.
The only way for one to find the possible error codes that will be
returned from a Win32 call is by trial and error, and, of course,
such results are incomplete and will change between Windows versions.
Applications that depend on this incompletely defined behavior are fragile.
Ten years ago I wrote that the Windows API was in many ways problematic.
Thanks to a Slashdot comment, I now know the reason.
Read and post comments 
