The following is intended as a general introduction to Win32s. Moreinformation can be found in the "Win32s Programmer's Reference" and byquerying for Knowledge Base articles on "Win32s".
The Win32 API consists of the Window 3.1 (Win16) API, with types stretchedto 32 bits, plus the addition of APIs which offer new functionality, likethreads, security, services, and virtual memory. Applications developedusing the Win32 API are called "Win32-based applications".
Win32s is a set of DLLs and a VxD which allow Win32-based applications torun on top of Windows or Windows for Workgroups version 3.1. Win32ssupports 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, whichreturn ERROR_NOT_IMPLEMENTED. Win32s also includes 4 new APIs which supportthe Universal Thunk (UT). For details on which API are supported underWin32s, refer to the individual API entries in the help file "Win32 APIReference." Among the new features gained from Win32 are structuredexception handling (SEH), FP emulation, memory-mapped files, named sharedmemory, and sparse memory.
Win32-based applications running on Windows 3.1 will generally be fasterthan their Win16 equivalents on Windows 3.1, particularly if they arememory or floating-point intensive. The actual speed improvement varieswith each application, because it depends on how often you cross the thunklayer. Each call which uses a thunk is no more than 10 percent slower thana direct call.
Win32s offers binary compatibility for Win32-based applications on Windows3.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.
For example, if the application is running under Windows 3.1 and a call ismade to one of the supported APIs, then the call returns successfully andoption A is executed. If the call is made while running under Windows NT,the call again returns successfully and option A should be executed.However, if running under Windows 3.1 and a Win32 API function is calledthat is unsupported, then an error code is returned and option B should beexecuted.
If, for example, option A were using a CreateThread() call, then option Bwould be alternative code, which would handle the task using a single-thread solution.
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 stackand the 16-bit entry point is called. The Win32 application has a 128Kstack. 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 the16-bit code.
There are other semantic difference between Windows 3.1 and Win32. Windows3.1 will run applications for Win32 nonpreemptively in a single, sharedaddress space, while Windows NT runs them preemptively in separate addressspaces. It is therefore important that you test your Win32-basedapplication on both Windows 3.1 and Windows NT.
If you need to call routines that reside in a 16-bit DLL or Windows from32-bit code, you can do this using the Win32s Universal Thunk or otherclient-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 usedbetween 16-bit Windows-based and Win32-based applications on both Windows3.1 and Windows NT. RPC is not supported from Win32-based applications.