Since window procedures that communicate using the standard Presentation Manager message conventions have no exterior interfaces aside from these messages, window procedures are essentially "black boxes" and are invisible to the application. It is thus possible to produce a number of window procedures to perform standard or often-used functions, and to store these window procedures in a library from which they may be accessed by a number of applications.
The recommended way to achieve this capability is to place such window procedures in an OS/2 dynamic link library. [See Dynamic Linking for an explanation of the concept of dynamic linking. ] Applications using these window procedures then reap the benefits of DLLs; namely that changes to window procedures contained in the DLLs do not require the applications to be re-linked and that multiple applications may use the same memory-resident copy of the window procedure code, since DLLs are re-entrant. The use of DLLs therefore maximizes the potential for code reuse, and facilitates the containment of change within a single application module.
Note that where existing 16-bit DLLs contain application objects, functions or resources required by 32-bit applications under OS/2 Version 2.0, these applications may access the 16-bit DLLs. This technique, known as mixed model programming, is discussed in Mixing 16-Bit and 32-Bit Application Modules.