Before COM There was a time not so long ago in software development when it was quite normal to distribute full source code and/or header files with third-party libraries In order to make use of these libraries, people simply compiled them (or included their header files) into applications The end result was a single executable that might contain code from many different vendors Since it was common for many developers to use the same third-party library, a version of the library might exist in the executables deployed with numerous products Executables tended to be relatively large and there was little or no code sharing between them Updating one of these third-party libraries required recompilation and/or relinking since the library was incorporated directly into the executable at compile time That all changed with the introduction of DLLs Almost overnight, it became quite common for third-party vendors to ship only header files and binaries Instead of being able to deploy a single executable, the developer would end up distributing a sometimes sizeable collection of DLLs with his or her application At runtime, it was up to the application to loadeither implicitly or explicitlythe DLLs provided by the thirdparty vendor As applications became more complex, it was not uncommon to see executables that required dozens of DLLs with complex interdependencies between them NOTE: This is, in fact, how Windows itself worksWindows is an executable with a large collection of dynamically linked libraries Windows apps make calls to the functions exposed by these DLLs This approach worked reasonably well, but it had several drawbacks One of the main ones was that the interfaces to these DLLs weren't object-oriented and therefore were difficult to extend and susceptible to being broken by even minor changes to an exposed function If a vendor added a new parameter to a function in its third-party library, the change might well break the code of everyone currently using that library The approach most vendors took to address this was simply to create a new version of the function (often with an "Ex" suffix or something similar) that included the new parameter The end result was call-level interfaces that became unmanageable very quickly It was common for third-party libraries (and even Windows itself) to include multiple versions of the same function call in an attempt to be compatible with every version of the library that had ever existed The situation quickly grew out of control, exacerbated by the fact that there was no easy, direct method for users of these libraries to know which of the many versions of a given function should be used Coding to these interfaces became a trial-and-error exercise that involved lots of scouring of API manuals and guesswork Another big problem with this approach was the proliferation of multiple copies of the same DLL across a user's computer Hard drive space was once much more expensive than it is now, so having multiple copies of a library in different places on an end user's system was something vendors sought to avoid Unfortunately, their solution to the problem wasn't really very well thought out Their answer was to put the DLLs their apps needed in the Windows system directory This addressed the problem of having multiple copies of the same DLL, but it introduced a whole host of other issues Chief among these was the inherent problems with conflicting versions of the same DLL If Vendor A and Vendor B depended on different versions of a DLL produced by Vendor C, there was a strong likelihood that one of their products would be broken by the other's version of the DLL If the interface to the DLL changed even slightly between versions, it was quite likely that at least one of the apps would misbehave (if it worked at all) when presented with a version of the DLL it wasn't expecting Another problem with centralizing DLLs was the trouble that arose from centralized yet unmanaged configuration information In the days before the Windows registry, it was common to have a separate configuration file (usually with a INI extension) for every application (and even multiple configuration files for some applications) These configuration files might include paths to DLLs that the application made use of, further complicating the task of unraveling DLL versioning problems Because these configuration files were not managed by Windows itself, there was nothing to stop an application from completely wiping out a needed configuration file, putting entries into it that might break other applications, or completely ignoring it These INI files were simply text files that an application could use or not use as it saw fit The progression used by Windows to locate DLLs was logical and well documented; however, the fact that an application might use Windows' LoadLibrary function and grab a DLL from anywhere it pleased on a user's hard drive might not mean anything in terms of knowing what code an application actually depended on The app might pick up a load path from a configuration file that no one else even knew about, or it might just search the hard drive and load what it thought was the best version of the library It was common for applications to have subtle interdependencies that made the applications themselves rather brittle We had come full circle from the days of bloated executables and little or no code sharingnow everyone depended on everyone else, with the installation of one app frequently breaking another ... user's system was something vendors sought to avoid Unfortunately, their solution to the problem wasn't really very well thought out Their answer was to put the DLLs their apps needed in the Windows system directory This addressed the. .. drawbacks One of the main ones was that the interfaces to these DLLs weren't object-oriented and therefore were difficult to extend and susceptible to being broken by even minor changes to an exposed function... quickly grew out of control, exacerbated by the fact that there was no easy, direct method for users of these libraries to know which of the many versions of a given function should be used Coding to these interfaces became a trial -and- error exercise