DLL Hell: Software Dependencies, Failure, and the Maintenance of Microsoft Windows

Abstract

Software is relational. It can only operate in correlation with the other software that enables it, the hardware that runs it, and the communities who make, own, and maintain it. Here, we consider a phenomenon called “DLL hell,” a case in which those relationships broke down, endemic to the Microsoft Windows platform in the mid-to-late 1990s. Software applications often failed because they required specific dynamic-link libraries (DLLs), which other applications may have overwritten with their own preferred versions. We excavate “DLL hell” for insight into the experience of modern computing, especially in the 1990s, and into the history of legacy class software. In producing Windows, Microsoft had to balance a unique and formidable tension between customer expectations and investor demands. Every day, millions of people relied on software that assumed Windows would behave a certain way, even if that behavior happened to be outdated, inconvenient, or just plain broken, leaving Microsoft “on the hook” for the uses or abuses that others made of its platform. But Microsoft was also committed to improving, repairing, and transforming their flagship product. As such, DLL hell was a product of the friction between maintenance and innovation. Microsoft embodied late 20th-century liberalism, seeking simultaneously to accommodate and to discipline various stake holders who had irreconcilable needs. DLL hell reveals the collective work, even when unsuccessful, of developing contractual norms for software as process and practice. Ultimately, many users became disaffected in the face of a perceived failure of technocratic expertise. We attend to implementation, use and misuse, management and mismanagement, in order to recover and reconstruct the complexities of a computing failure.