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.. Almost overnight, it bec
Trang 1There 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 third-party 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
Trang 2drawbacks 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
Trang 3at 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