To Home page

Bitrot and Protocol Negotiation

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:

  1. The GUID, the globally unique identifier, a very large random number, a number so large that it was unlikely that any two libraries or two versions would randomly choose the same number. Compiled software interacts with other compiled software using this identifier.
  2. The nickname, a human readable user friendly name and version number, which is not necessarily globally unique.  “Nickname” is Zooko's terminology, not what Microsoft calls them. Humans writing code to be interpreted may use the nickname, though the correct behavior would be for the code writer to use the petname, and for the development environment to insert the appropriate GUID, if no GUID is specified, and adjust the petname to its local value if the GUID is specified.
  3. It may, and should, have a petname, its registry key, a humanly readable user friendly local name which is guaranteed unique on the particular computer on which the library (ActiveX object) has been installed, but is not necessarily meaningful to the world at large, though this is not quite implemented.  Again, petname is Zooko's terminology, not what Microsoft calls them.  The petname, if it exists, is automatically generated from the nickname.  Error messages should use the petname, though they tend to use the nickname.

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