So then: if some Hero (or fool?) ran amok, disassembled several of these .dll versions and found the bad logic in "most?" of them - would the programmer generate a filter == add more code to SeaMonkey: that detects the version and self-modifies accordingly? (Would this not also slow things, each time that display dll gets called? Decent tradeoff, perhaps, but more chances for incompatibilities elsewhere?)

I don't know about Mozilla but in my experience there are two popular ways of dealing with this in code. Some applications use a fall back system, where they try method A and if that fails they switch to using method B and so on. This works well can you can detect failures of an interface, but for many of the nasty problem you either can't or by the time you can it is too late. The second is to determine which versions of key DLLs are installed and modify behavior accordingly when the program starts. This works well when you know exactly which DLLs have which problems, but in reality it is often hard to tell.

Most custom built business applications use neither. They just are designed against a specific version of the DLL and if that turns into a problem later it is forced onto the machine as part of the install process. If that can't be done they simply stick with the old version until they have no choice but fix the problem.

The company I'm working for now was running Windows NT on some desktops till this year because a key application wouldn't work on XP.

Jay

DLLs where designed for the era when disk space and memory where very limited. The idea was you only ever needed one foo.dll on a system and would ever only load one foo.dll into memory. If another application called foo.dll, Windows just passed a reference to the already loaded copy.

At the time it was a sensible solution, though poorly implemented. Microsoft made two key mistakes from the start, failing to clearly separate system and application DLLs, and not providing a good way of uniquely naming or providing version numbers for DLLs.

What makes it so typical of Microsoft is that they where copying something from Unix, and managed to mess it up. Shared Libraries under Unix are not what I would call elegant. But the system does work and covers all of the major issues.

Jay