Dynamic Link Libraries

Dynamic Link Libraries grew in popularity in the mid-1990s as simple mechanisms for linking and sharing software code with Windows applications at runtime. In concept, the DLL did for Windows what earlier terminate-and-stay-resident programs tried less successfully to do for DOS.

Because DLLs are called at runtime, they can be modified and updated without having to recompile the larger application that uses them. In addition, multiple applications can use the services or data within a communal DLL, thus reducing memory demands in multithreaded applications.

DLLs also save on memory because they don't get loaded at the same time as the main (calling) program. A DLL file isn't loaded and run until it's needed. For example, if a user is running Microsoft Word or Excel, he can work for a long time without needing to load the printer DLL into memory. Only when the user decides to print the document is the printer DLL loaded and run-and then unloaded.

DLLs were created in the days of the client/server computing movement, when developers needed a way for applications to interact with other programs and systems. But as the use of DLLs on individual PCs increased, so did compatibility and security problems.

"The approach is great in a single-user format, but not in a robust environment," says Frederick G. Kohun, associate dean of the School of Communications and Information Systems at Robert Morris College in Moon Township, Pa. "What scares me about DLLs on the client end is they make all the machines within the organization vulnerable to virus attacks. Every time you do a runtime load, [a virus] can attach to the operating system."

If you've gotten that far, then you've probably heard the phrase "DLL hell." This is a situation caused when an application is installed that requires a specific, often older version of a "standard" Windows DLL. The new application installs the old version, replacing the newer one, and as a result, some other applications may no longer work properly. The situation gets worse as new application releases and new versions of Windows increase the number of DLL versions.

Nevertheless, DLLs set the stage for more sophisticated offspring called software components, the encapsulated applications now being built around COM/DCOM from Microsoft Corp., the Common Object Request Broker Architecture (CORBA) from Needham, Mass.-based Object Management Group Inc., and the Java standards from Sun Microsystems Inc.

DLL Makeovers

Software components carry on the DLL tradition of allowing programmers to build reusable code libraries in binary form and not forcing customers to recompile applications, notes Francis Beaudet, chief architect at Macadamian Technologies Inc., a software development and consulting firm in Ottawa. Beaudet specializes in developing interactive Web applications using Enterprise JavaBeans.

"Component architectures like DCOM or CORBA build on the concept of the DLL by adding more functionality, including networking support and authentication," he says. "You could even say that COM is just a smarter, better way to use DLLs."

Software developers are now relying on the more advanced software-component option rather than on standard DLLs. That's partly because the standards that define the makeup and activity of components makes the dynamic linking of libraries and applications more efficient and less vulnerable to viruses. And instead of having DLLs residing on individual PCs as in the early client/server era, systems architects are finding central homes for the software components.

"We now see three layers: the graphical layer, the middleware layer and the data warehouse layer," says Kohun. "The notion is that a DLL no longer resides on the desktop. They're now at the middleware level."

"[DLLs] are now hidden behind a layer of glue code that takes charge of finding, loading and linking your application with the DLL," Beaudet says.

The result: the widespread availability of reusable components, shared objects and interfaces among Web-based applications. "But in the back end, it's still the same old DLL," Beaudet says. "The mechanism itself will continue to work as it always worked."

In fact, when you access a Web page with an ActiveX component, your browser is downloading a DLL from the Web server, installing it on your PC and linking with it.

"It's now called a component, but that DLL has the same internal structure as the ones that were installed on your PC with Windows 95 six years ago," Beaudet says. "Only the delivery method changed."

Dialing for DLLs
1A Windows application launches the “LoadLibrary” or “LoadLibraryEx” commands to find the DLL.
2If the command succeeds in its search, it loads the DLL into the same virtual address space as the application.*
3The application then sends the “GetProcAddress” command to determine the addresses of the services or data associated with the DLL.
4“GetProcAddress” returns the addresses to the application.
5The application employs the services or data of the DLL.
6When finished with the DLL, the application invokes the “FreeLibrary” or ”FreeLibraryAndExitThread” command to remove the DLL from the virtual address space.
*If the DLL search fails, LoadLibrary or LoadLibraryEx send back a Null response. At that point, the application may seek out an alternative DLL, or the user of the application may manually type in the correct path to the intended DLL.

Join the newsletter!

Error: Please check your email address.

More about MicrosoftObject Management Group

Show Comments