Diomidis Spinellis blog dds logo

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.

    Comments   Toot! Share

    Navigation
    blog contents
    dds blog
    dds home
    comments
    « Handling Downtime
    » The Tools we Use
    Tagged as




    Become a Unix command line wizard
    edX MOOC on Unix Tools: Data, Software, and Production Engineering
    Debug like a master
    Book cover of Effective Debugging
    Compute with style
    Book cover of The Elements of Computing Style
    Syndication
    This blog is also available as an RSS feed:

    Recent posts
    Twitter's overrated dissemination capacity (2023-04-02)
    The hypocritical call to pause giant AI (2023-03-30)
    AI deforests the knowledge’s ecosystem (2023-03-16)
    How I fixed git-grep macOS UTF-8 support (2022-10-12)
    The sorry state of software quality (2022-03-10)
    Rather than alchemy, methodical troubleshooting (2021-11-27)
    The Evolution of the Unix System Architecture (2021-06-18)
    Reviving the 1973 Unix text to voice translator (2021-01-02)
    Fast database UPDATE/DELETE operations (2020-12-10)
    Raspberry Pi 400 vs ZX Spectrum (2020-11-02)

    Last modified: Thursday, June 21, 2007 11:28 am

    Creative Commons Licence BY NC

    Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.