From the Trenches
Directions / Commentary
Learning to Share
The problem of shared code libraries has been around since the dawn of computing. The typical example used to illustrate why a shared code library should be used is the C run-time library. In this scenario, every time a programmer wrote a program in C, they used the C run-time library. Therefore, each application would have its own copy of the library compiled right into the executable.
One solution to this problem was the introduction of DLLs in Windows. No longer was it necessary to have multiple copies of the C run-time library lying around your disk, taking up precious disk space. Furthermore, running multiple applications simultaneously that relied on the run-time library wouldn’t require the entire library to be loaded in memory multiple times. This ushered in a new era of computing, where third-party companies sell libraries to you, the programmer, so you don’t have to program something that’s already been done.
Lately, there has been much discussion about where applications should place shared DLLs. The two most accepted places for third-party DLLs are the \Windows\System directory, or in a private directory. Due to paranoia in the software industry that a newer version of a DLL may introduce problems with existing applications, some recent publications have even gone so far as to recommend using private directories for all non-system DLLs. Each argument has its merits, but to help protect yourself from latent problems, you should place these files in the \System directory.
But what’s “third party?” By the very definition of this phrase, we can define our argument. Is third-party supposed to be anything that isn’t part of the core Windows operating system? If so, that means MS Office, Visual C++ run-time libraries, Internet Explorer, and even Delphi run-time packages should all be in their own private directories. If we say that certain applications should be exempt from the third-party definition, then who will decide which applications are considered third-party? On the other hand, if every application should put its DLLs in a private directory, then why use DLLs at all? The same thing could be accomplished by linking the code straight into the EXE.
Imagine the outcry of outraged users because they don’t have a central repository to ease the burden on their disk space, memory requirements, and system maintenance issues. We already have that feature, it’s called the \System directory. To blame the strategy because some applications and third-party DLL vendors can’t play by the rules, seems to not recognize the central need for this strategy to exist. After all, even the good old DOS and UNIX machines presented users with configuration problems. Some of these problems even related to having improper and conflicting versions of software modules (e.g. TSRs and device drivers) loaded at the same time.
Lastly, consider this scenario: Vendor A writes an application that uses a fairly common third-party DLL. They subscribe to the theory that the DLL belongs in a private directory. Now you come along and write an application that uses the same DLL. No matter what strategy you believe in, there’s already a very large chance for a defect to surface in your program. How? If the user that purchased both software packages runs Application A and then runs your application, you will be using the copy of the DLL in Application A’s directory! If your application relies on a newer version of the DLL than the one provided by Vendor A, Vendor A can make your application crash. You might say, “This will never happen to me,” but the truth is, it happens all the time.
We live, work and play in a multi-tasking, multi-application operating system. As developers, we need to ensure the highest level of probability that our applications won’t fail. As soon as you try to outsmart the way things are supposed to work, you will find yourself engaged in an uphill battle that you’ll eventually lose. It’s far better to fully understand the scope of the problem, and how you might help alleviate it, rather than try to insulate yourself in a corner of the operating system.
If anything, this should be a call to action for:
• third-party developers to be responsible in releasing new versions 100 percent compatible with previous versions;
• installation application companies to find an effective work-around;
• Microsoft to devise and implement a new strategy that provides the benefits of DLLs without the current problems; and
• application developers to play by the rules.
Dan Miser is a Design Architect for Stratagem, a consulting company in Milwaukee. He has been a Borland Certified Client/Server Developer since 1996, and is a frequent contributor to Delphi Informant. You can contact him at http://www.execpc.com/~dmiser.
Mr Miser talks about shared code libraries, using the C run-time library as an example.
Mr Miser talks about shared code libraries.