blog dds


The Double-Edged Sword of Proprietary Platforms

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, or share through   

    Creative Commons License Last modified: Thursday, June 21, 2007 11:28 am
    Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-Share Alike 3.0 Greece License.