To Home page
One particular case of the bitrot problem was the Microsoft Windows problem known as “DLL Hell”, DLLs being binary dynamically linked libraries in Microsoft Windows.
Over time these libraries tended to be upgraded, improved, and changed, and programs written for the old libraries would develop bugs with the new libraries, sometimes these bugs were crash and burn bugs, “bitrot”, sometimes there were unexpected interactions between programs using the same library, which caused one program to accidentally foul up another, or enabled one program to maliciously manipulate another.
This problem was solved. The solution was “COM”. In COM, dynamic linking necessarily involves version negotiation. Mandatory version negotiation largely relieves bitrot.
In COM, in accordance with Zooko's triangle, each version of a library's behavior, each library interface, has three names. Describing those names and their behavior from the point of view of Zooko's triangle, which is not how most Microsoft programmers would describe them or think about them:
In order for a program to connect to any COM library (what Microsoft calls an ActiveX object), it has to do protocol negotiation in order to get an interface, has to ask for the interface by its globally unique identifier, so the library always knows what version of the library the program expects, and will provide that behavior, or, if it cannot provide that behavior, the program will fail immediately with an error message explaining the problem.
This solution worked. It solved DLL hell, solved bitrot.
Windows implementation of this solution was less successful in dealing with another problem – library calls often cross thread and process boundaries. They provided a general purpose threading solution, also part of COM, which was hideously complicated and failed dismally. But they fixed bitrot.
Cross thread and cross process interactions usually wind up being implemented as message streams and message queues. The correct approach is to make this explicit, to define the interface as a message protocol, rather than attempting to hide the underlying message queue behavior as Microsoft did and pretend it is an ordinary synchronous object method. Where COM runs on top of message queues, as it does whenever a call crosses thread or process boundaries, the result is intolerable obscurity, complexity, and inefficiency – which is still a lot better than the bitrot that it fixed.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License