General Overview of Win32s

• Microsoft Win32s versions 1.1, 1.2, 1.3, 1.30c

SUMMARY

The following is intended as a general introduction to Win32s. More information can be found in the "Win32s Programmer's Reference" and by querying for Knowledge Base articles on "Win32s".

MORE INFORMATION

General Overview

The Win32 API consists of the Window 3.1 (Win16) API, with types stretched to 32 bits, plus the addition of APIs which offer new functionality, like threads, security, services, and virtual memory. Applications developed using the Win32 API are called "Win32-based applications".

Win32s is a set of DLLs and a VxD which allow Win32-based applications to run on top of Windows or Windows for Workgroups version 3.1. Win32s supports a subset of the Win32 API, some directly (like memory management) and some through thunks to the 16-bit systems (particularly GDI and User). Win32s contains function stubs for the APIs that are not supported, which return ERROR_NOT_IMPLEMENTED. Win32s also includes 4 new APIs which support the Universal Thunk (UT). For details on which API are supported under Win32s, refer to the individual API entries in the help file "Win32 API Reference." Among the new features gained from Win32 are structured exception handling (SEH), FP emulation, memory-mapped files, named shared memory, and sparse memory.

Win32-based applications running on Windows 3.1 will generally be faster than their Win16 equivalents on Windows 3.1, particularly if they are memory or floating-point intensive. The actual speed improvement varies with each application, because it depends on how often you cross the thunk layer. Each call which uses a thunk is no more than 10 percent slower than a direct call.

Binary Compatibility

Win32s offers binary compatibility for Win32-based applications on Windows 3.1 and Windows NT.

When you call a Win32 API, two options should be allowed:

• Option A: Your code should allow for a successful return from the function call.
• Option B: Your code should allow for an unsuccessful return from the function call.

If, for example, option A were using a CreateThread() call, then option B would be alternative code, which would handle the task using a single- thread solution.

Programming Issues

Win32-based applications cannot use MS-DOS and BIOS interrupts; therefore, the Win32s VxD has Win32 entries for each Interrupt 21 and the BIOS calls.

The Win32s DLLs may thunk to Win16 when a Win32 application makes a call. The 32-bit parameters are copied from the 32-bit stack to a 16-bit stack and the 16-bit entry point is called. The Win32 application has a 128K stack. When switching to the 16-bit side via UT, the same stack is used, and a 16:16 stack pointer is created which points to the top of the stack. The selector base is set so that there is at least an 8K stack for the 16-bit code.

There are other semantic difference between Windows 3.1 and Win32. Windows 3.1 will run applications for Win32 nonpreemptively in a single, shared address space, while Windows NT runs them preemptively in separate address spaces. It is therefore important that you test your Win32-based application on both Windows 3.1 and Windows NT.

If you need to call routines that reside in a 16-bit DLL or Windows from 32-bit code, you can do this using the Win32s Universal Thunk or other client-server techniques. For a description of UT, please see the "Win32s Programmer's Reference" and the sample UTSAMPLE.

DDE, OLE, WM_COPYDATA, the clipboard, metafiles, and bitmaps can be used between 16-bit Windows-based and Win32-based applications on both Windows 3.1 and Windows NT. RPC is not supported from Win32-based applications.