As you've seen, a Windows program is an executable file that generally creates one or more windows and uses a message loop to receive user input. Dynamic link libraries are generally not directly executable, and they do not receive messages. They are separate files containing functions that can be called by programs and other DLLs to perform certain jobs. A dynamic link library is brought into action only when another module calls one of the functions in the library.
The term dynamic linking refers to the process that Windows uses to link a function call in one module to the actual function in the library module. ”Static linking“ occurs when you run LINK to create a Windows .EXE file from various object (.OBJ) modules and run time library (.LIB) files. Dynamic linking occurs at run time.
TKERNEL.EXE, USER.EXE, and GDI.EXE files, the various driver files such as KEYBOARD.DRV, SYSTEM.DRV, and SOUND.DRV, and the video and printer drivers are all dynamic link libraries. These are libraries that all Windows programs can use.
The various font resource files with the extension .FON are ”resource-only“ dynamic link libraries. They contain no code and no data but instead have fonts that all Windows programs can use. Thus, one purpose of dynamic link libraries is to provide functions and resources that can be used by many different programs. In a conventional operating system, only the operating system itself contains routines that other programs can call on to do a job. In Windows, the process of one module calling a function in another module is generalized. In effect, by writing a dynamic link library, you are writing an extension to Windows. Or you can think of dynamic link libraries (including those that make up Windows) as extensions to your program. The code, data, and resources in a dynamic link library module are shared among all programs using the module.
Although a dynamic link library module may have any extension (such as .EXE or .FON), the standard extension in Windows 3 is .DLL. Only dynamic link libraries with the extension .DLL will be loaded automatically by Windows. If the file has another extension, the program must explicitly load the module using the LoadLibrary function.
You'll generally find that dynamic libraries make most sense in the context of a large application. For instance, suppose you write a large accounting package for Windows that consists of several different programs. You'll probably find that these programs use many common routines. You could put these common routines in a normal object library (with the extension .LIB) and add them to each of the program modules during static linking with LINK. But this approach is wasteful, because each of the programs in this package contains identical code for the common routines. Moreover, if you change one of these routines in this library, you'll have to relink all the programs that use the changed routine. If, however, you put these common routines in a dynamic link library called (for instance) ACCOUNT.DLL, then you've solved both problems. Only the library module need contain the routines required by all the programs (thus requiring less disk space for the files and less memory space when running two or more of the applications), and you can make changes to the library module without relinking any of the individual programs.
Dynamic link libraries can themselves be viable products. For instance, suppose you write a collection of three-dimensional drawing routines and put them in a dynamic link library called GDI3.DLL. If you then interest other software developers in using your library, you can license it to be included with their graphics programs. A user who has several of these programs would need only one GDI3.DLL file.