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.
For example, if the application is running under Windows 3.1 and a call is
made to one of the supported APIs, then the call returns successfully and
option 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 called
that is unsupported, then an error code is returned and option B should be
executed.
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.