When a 32-bit application module creates a window, and the window procedure for that window resides in a 16-bit module (either statically linked or in a DLL), the calling routine must explicitly declare the 16-bit nature of the window procedure's entry point when registering the window class. This may become rather complex, since it involves invoking a 32-bit entry point from a 32-bit module, but passing a 16-bit entry point as a parameter.
A simpler solution is to build a registration routine within the 16-bit module, which registers the window class and creates the window. The 32-bit module then need only invoke this routine, and allow for the resulting 16-bit window handle. This technique has the added advantage that Presentation Manager records the fact that the window was registered from a 16-bit module, and will automatically perform thunking for system-defined message classes. The technique is illustrated in Figure "Creating a 16-bit Window From Within a 32-bit Module".
Since the 16-bit module would typically be a DLL, the registration routine is declared in the 16-bit module as an exportable entry point using the EXPENTRY keyword.
The 32-bit module declares the registration routine MakeMyWindow() as a 16-bit function using the #pragma linkage directive with the far16 keyword. Since in 16-bit code, the EXPENTRY keyword forces use of the pascal calling convention, the directive also specifies this calling convention. Note that if the registration routine and the window procedure were to reside in a DLL, this declaration would typically take place within a header file provided by the developer of the DLL.
The 32-bit module invokes the registration routine that registers the window class and creates the window. The registration routine then returns the window handle to the 32-bit module, which stores it in 16:16 format. Note that the registration routine in the 16-bit module is not aware that it is being called from a 32-bit module.
This approach allows the same DLL to be accessed by both 16-bit and 32-bit applications concurrently. The developer of the DLL simply provides two separate header files containing declarations of the DLL's entry points, in the appropriate format for each programming environment.