Win32 Application Programming Interface | Microsoft Windows Architecture for Developers Training Kit

The Win32 application programming interface (Win32 API) allows applications to capitalize on the power of the Windows family of operating systems. The Win32 functions, messages, and structures form a consistent and uniform API for Windows 95 and Windows NT. Using the Win32 API, applications can be developed to run successfully on all platforms while retaining their ability to take advantage of unique features and capabilities of any given platform.

Many API functions are supported directly by programs such as Visual Basic. For example, you can call the Win32 API MessageBox function, or you can use the Visual Basic msgbox function instead. The inherent Visual Basic calls are typically easier to program. However, there are many cases when developers can utilize the functionality of the Win32 API.

Win32 API Core Code

The core code of Win32 API is primarily made up of three dynamic-link libraries (DLLs): USER32, GDI32, and KERNAL32.

click to view at full size.

Figure 1.10 The Win32 API DLLs

USER32

User32.dll and User32.exe create and maintain windows on the screen, carrying out all requests to create, move, size , or destroy a window. User .exe also handles requests regarding the icons and other components of the user interface. User.exe directs input to the appropriate application from the keyboard, mouse, and other input sources.

GDI32

Gdi32.dll and Gdi.exe control the Graphics Device Interface (GDI). The GDI executes graphics operations that create images on the system display and other devices. This includes:

Drawing to the screen.
Drawing to the printer.
Turning pixels on and off.

KERNEL32

Kernel32.dll handles base operating system functions such as:

Memory management
File input and output
Program loading
Program execution

Note
When declaring API functions in Visual Basic, the 32-bit functions are case sensitive while the equivalent 16-bit functions are not. This is important when porting a 16-bit application to a 32-bit version.

32-Bit Versus 16-Bit Components

Windows 95 also supports 16-bit versions of the User, GDI, and Kernel components for backward compatibility. A combination of 16-bit and 32-bit code is used to maintain compatibility with existing applications and drivers, and to improve system performance over Windows 3.1.

Windows 95 deploys 32-bit code wherever it significantly improves performance without sacrificing application compatibility. Windows 95 still contains 16-bit code for three fundamental reasons:

Code for16-bit systems provides backwards compatibility for applications and drivers designed to run on Windows 3.1.
In few cases, 16-bit code is faster than the equivalent 32-bit code.
Using 32-bit code requires more memory than an equivalent amount of 16-bit code.

One of the main goals of Windows 95 is to work efficiently on a system that has limited amounts of RAM. The use of 16-bit code facilitates this requirement.

Windows 95's I/O subsystems and device drivers, such as networking and file systems, are fully 32-bit. All of the memory management and scheduling components (the kernel and virtual memory manager) are also 32-bit. At times you may need to call a 32-bit function from a 16-bit application, or vice versa. This is done through a procedure called thunking .

Thunking

Thunking occurs when an operating system converts a 16-bit function call to a 32-bit function call. Windows 95 and Windows NT do not allow processes to include both 16-bit and 32-bit code. Thunking allows code on one side of the 16- and 32-bit process boundary to call into code on the other side of the boundary.

Windows 95	Windows NT
Generic Thunks	X	X
Flat Thunks	X

Each platform employs one or more thunking mechanisms:

Generic thunks allow a 16-bit Windows-based application to load and call a Win32-based DLL on Windows NT and Windows 95.
Flat thunks allow a Win32-based application to load and call a 16-bit DLL, or a 16-bit application to load and call a Win32-based DLL.