Behavior of Win32 Functions Inside 16-Bit Processes

When writing applications for Windows 95/98, you typically use 16-bit to 32-bit thunks for implementing callback thunks on 32-bit processes. You can also use them to execute 32-bit code in 16-bit processes. This method can improve performance and multitasking, but significant restrictions apply to 32-bit code executed in the context of a 16-bit process.

• Win32-based applications use a 1-MB stack. However, 32-bit code executed in the context of a 16-bit process uses the approximately 64K stack reserved by the 16-bit application. The 16-bit application's stack is usually smaller than 64K, because it resides in the default data segment, along with global data, static data, and the local heap.
• The 16-bit process cannot create new threads. Certain Win32 functions, such as those supporting common dialog boxes or those supporting console applications, create threads on behalf of the calling application. You cannot call these functions in the context of a 16-bit process.
• The 16-bit process cannot create fibers.
• No 16-bit application gets processing time while a 16-bit application blocks without yielding. Thunking into 32-bit code releases the 16-bit subsystem to other 32-bit processes, but other 16-bit processes are still blocked unless your process explicitly yields (typically as a result of calling the GetMessage function). In other words, 16-bit applications still multitask cooperatively, even when executing 32-bit code. A common problem occurs if you use the CreateProcess function to launch a 16-bit application, then wait for it to set a synchronization object. If the application does not yield, the child application never runs, so the object is never set to the signaled state, and deadlock occurs.

In general, 32-bit code running in the context of a 16-bit process should be limited to code that uses the 32-bit heap functions, memory-mapped file functions, file functions, and functions involving the current process and thread. You can also use GDI, dialog box, message box, and message functions from 32-bit code running in the context of a 16-bit process. You should avoid using third-party libraries unless you are sure they work safely in a 16-bit environment.