Most programmers are familiar with static linking; an application calls a routine or procedure whose code is not found in the application's source file. The routine is external to your source file and is declared as such. When the source file is compiled, the compiler places an external reference for the routine in the application's object (.OBJ) file. To create the executable file (.EXE) for the application, the application's object file is linked with an object file that contains the code for the routine. The result is an EXE file that contains the application code, as well as a copy of the code for the routine. The following figure illustrates the process of building a statically linked application.

   My_Application.OBJ
  ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
  ³ EXTERNAL               ³
  ³     Your_Routine       ³
  ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
  ³ .                      ³                  My_Application.EXE
  ³ .                      ³                 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
  ³ CALL ???; Your_Routine ÃÄÄ¿              ³ .                ³
  ³                        ³  ³  ÚÄÄÄÄÄÄ¿    ³ .                ³
  ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ  Ãij LINK ÃÄÄij CALL xxx         ³
                              ³  ÀÄÄÄÄÄÄÙ    ³ .                ³
   Your_Library.OBJ           ³              ³                  ³
  ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿  ³         xxx: ³ Your_Routine:    ³
  ³ PUBLIC                 ³  ³              ³                  ³
  ³     Your_Routine       ³  ³              ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
  ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´  ³
  ³                        ³  ³
  ³ Your_Routine:          ³  ³
  ³                        ÃÄÄÙ
  ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Static Linking

When OS/2 loads a statically linked program, all the code and data are contained in a single EXE file and the system can load it into memory all at once.

The advantages and disadvantages of static linking are summarized in the following table.

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³Advantages                    ³Disadvantages                 ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³Compile in pieces             ³External routines built into  ³
³                              ³EXE (making EXEs larger)      ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³Can create libraries of       ³EXE cannot be changed without ³
³routines that can be linked   ³relinking.                    ³
³with applications.            ³                              ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³                              ³External routines cannot be   ³
³                              ³shared (duplicate copies of   ³
³                              ³libraries).                   ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Dynamic linking permits several applications to use a single copy of an executable module. The executable module is completely separate from the applications that use it. Several functions can be built into a DLL, and applications can use these functions as though they were part of the application's executable code. You can change the dynamically-linked functions without recompiling or relinking the application.

The advantages of dynamic linking are:

Reduced memory requirements

Many applications can use a single DLL simultaneously. Since only one copy of the DLL is in memory, this saves memory space and, in general, the code is discardable.

Simplified application modification

An application can be enhanced or modified simply by changing a DLL. For example, if an application uses a DLL to support video output, several displays can be supported by different DLLs. The application can use the DLL that supports the appropriate display.

Flexible software support

DLLs can be used for after-market support. In the display-driver example, a new DLL can be provided to support a display that was not available when the application was shipped. Similarly, a database application can support a new data-file format with a new DLL.

Transparent migration of function

The DLL functions can be used by applications without any understanding of how the functions actually do their work. Future changes to the DLL are transparent to the application, as long as the input and output parameters remain the same.

Multiple programming language support

A function in a DLL can be used by an application written in any programming language, as long as the application understands the function's calling convention.

Application-controlled memory usage

Applications can make decisions about which DLL routines they want to load into memory and use. If a DLL is not used, it does not have to be loaded.

DLLs can be used to implement subroutine packages, subsystems, and interfaces to other processes. In OS/2:

• Some DLLs are interfaces to the kernel.

  The worker routines for the OS/2 API reside in the OS/2 kernel. Applications, which run at privilege level 3, usually can make direct calls to the kernel, which runs at privilege level 0. Some calls, however, must be linked through a DLL. For example, an application that calls DosOpen is linked to the DLL DOSCALL1.DDL. This library contains the definitions for some system functions. When a system function is called, OS/2 makes the call to the kernel on behalf of the application.

• Some DLLs are interfaces to devices.

  DLL subsystems can virtualize devices and manage the device for its clients.

• Some DLLs provide an open system architecture for software.

  Add-ons to OS/2 can be provided easily and by anyone.

OS/2 provides two varieties of dynamic linking: load-time and run-time. In load-time dynamic linking, references are resolved when an application is loaded. In run-time dynamic linking, references are resolved when the application runs.