The technique described above handles messages passed to a window in a 16-bit module. However, messages passed from that window to the 32-bit module may also require thunking. In order to perform this thunking, the 32-bit application may define a thunk procedure and register this procedure to Presentation Manager, which then invokes the thunk procedure whenever a message is passed from within the window.
This registration is achieved using the WinSetWindowThunkProc() function, which is illustrated in Figure "Mixed Model Programming - WinSetWindowThunkProc() Function".
The WinSetWindowThunkProc() function call is made from the 32-bit module. Since the window class for the window has been registered in the 16-bit module, Presentation Manager recognizes that the thunk procedure is to handle 16-bit to 32-bit conversion.
A thunk procedure may be deregistered, by issuing a WinSetWindowThunkProc() function call with the thunk procedure entry point address set to NULL.
Whenever Presentation Manager invokes a thunk procedure for a message, it passes the normal four parameters accepted by a window procedure, along with the entry point address of the window procedure to which the message was to be passed. This may be the window procedure defined for the destination window when its class was registered, or a subclass window procedure defined by the application. Thus thunking may take place, irrespective of whether a window has been subclassed.
A sample thunk procedure is shown in Figure "Mixed Model Programming - Thunk Procedure".
The thunk procedure is invoked whenever a message is passed by the window in the 16-bit module to a window in the 32-bit module. The thunk procedure is similar in structure to a "normal" window procedure, but need contain cases only for application-defined message classes, since thunking for system-defined message classes is performed by Presentation Manager.
Note that since the thunk procedure is invoked by Presentation Manager, it must use the system linkage convention, and is thus declared using the EXPENTRY keyword.
In Figure "Mixed Model Programming - Thunk Procedure", the 16-bit window contains two application-defined message classes, WMP_MSG1 and WMP_MSG2. The first of these contains pointers in both parameters, and thus both parameters are thunked by the thunk procedure. The second message class contains a pointer in the first message paramater only; the second may contain an integer or some simple value parameter which does not require explicit thunking. Thunking is performed using the DosSeltoFlat() function provided by OS/2 Version 2.0.
After performing the necessary thunking, the thunk procedure directly calls the window procedure entry point supplied by Presentation Manager when the thunk procedure is invoked. Note that this is one of the few instances where direct invocation of a window procedure should be used. The correct sequence of message processing is preserved in this case because the thunk procedure itself is invoked either synchronously or asynchronously by Presentation Manager, depending upon whether the message was sent or posted by the 16-bit window.
An alternative to the use of the DosSeltoFlat() function is the explicit use of the Compability Region Mapping Algorithm discussed in OS/2 Version 2.0 - Volume 1: Control Program. This algorithm is implemented in the subroutine CRMA16to32 shown in Figure "16:16 to 0:32 Address Conversion".
The use of the DosSeltoFlat() function should be the preferred option, since the CRMA routines may fail under certain circumstances. Explicit use of CRMA should be restricted to those situations where special processing must be performed on the parameters being passed.