Created: February 1994
The Microsoft® Win32® Application Programming Interface (API) allows applications to exploit the power of 32 bits on the Microsoft Windows® family of operating systems. The Win32 functions, messages, and structures form a consistent and uniform API for all of Microsoft's 32-bit platforms: Windows 95, Windows NT™ 3.1, and Windows 3.1 with Win32s™. Using the Win32 API, you can develop applications that run successfully on all platforms while still being able to take advantage of unique features and capabilities of any given platform.
With a few minor exceptions, Microsoft ensures consistent and uniform behavior of the Win32 APIs across all platforms. Differences in the implementation of the Win32 API depend on the capabilities of the underlying features of the platform. The most notable difference is that some Win32 APIs carry out their tasks only on the more powerful platforms. For example, security functions are only available on the Windows NT operating system. Most other differences are system limitations, such as restrictions on the range of values or the number of items a given function can manage. For more information about system limitations, see "Windows 95 System Limitations" and "Win32s System Limitations" later in this article.
Window management gives your applications the means to create and manage a user interface. Using the window management functions, you create and use windows to display output, prompt for user input, and carry out the other tasks necessary to support interaction with the user. Nearly all applications create at least one main window.
Applications define the general behavior and appearance of their windows by creating window classes and corresponding window procedures. The window class identifies default characteristics, such as whether the window processes double clicks of the mouse buttons or has a menu. The window procedure contains the code that defines the behavior of the window, carries out requested tasks, and processes user input.
Applications generate output for a window using the graphics device interface (GDI) functions. Because all windows share the display screen, applications do not receive access to the entire screen. Instead, the system manages all output so that it is aligned and clipped to fit within the corresponding window. Applications can draw in a window in response to a request from the system or while processing input messages. When the size or position of a window changes, the system typically sends a message to the application requesting that it paint any previously unexposed area of its window.
Applications receive mouse and keyboard input in the form of messages. The system translates mouse movement, mouse button clicks, and keystrokes into input messages and places these messages in the message queue for the application. The system automatically provides a queue for each application. The application uses message functions to extract messages from the queue and dispatch them to the appropriate window procedure for processing.
Applications can process the mouse and keyboard input directly or let the system translate this low-level input into command messages by using menus and keyboard accelerators. You use menus to present a list of commands to the user. The system manages all the actions required to let the user choose a command, then sends a message identifying the choice to the window procedure. Keyboard accelerators are application-defined combinations of keystrokes that the system translates into messages. Accelerators typically correspond to commands in a menu and generate the same messages.
Applications often respond to command messages by prompting the user for additional information with dialog boxes. A dialog box is a temporary window that displays information or requests input. A dialog box typically includes controls—small, single-purpose windows—that represent buttons and boxes through which the user makes choices or enters information. There are controls for entering text, scrolling text, selecting items from a list of items, and so on. Dialog boxes manage and process the input from these controls, making this information available to the application so that it can complete the requested command.
Window management functions provide other features related to windows. For example, the clipboard functions provide the means to copy and paste information within the same window, between windows in the same application, and between windows in different applications. Applications also use the clipboard functions to carry out dynamic data exchange (DDE). DDE operations let applications exchange information without requiring specific direction from the user.
For more information about the window management functions, see the Microsoft Win32 Programmer's Reference.
Graphics device interface (GDI) provides functions and related structures that your applications can use to generate graphical output for displays, printers, and other devices. Using GDI functions, you can draw lines, curves, closed figures, paths, text, and bitmapped images. The color and style of the items you draw depend on the drawing objects—pens, brushes, and fonts—that you create. Use pens to draw lines and curves, brushes to fill the interiors of closed figures, and fonts to write text.
Applications direct output to a given device by creating a device context for that device. The device context is a GDI-managed structure containing information about the device, such as its operating modes and current selections. An application creates a device context by using device context functions. GDI returns a device context handle that is used in subsequent calls to identify the device. For example, using the handle, an application can retrieve information about the capabilities of the device, such as its technology type (display, printer, or other device) and the dimensions and resolution of the display surface.
Applications can direct output to a physical device, such as a display or printer, or to a "logical" device, such as a memory device or metafile. Logical devices give applications the means to store output in a form that is easy to subsequently send to a physical device. Once an application records output in a metafile, it can play that metafile any number of times, sending the output to any number of physical devices.
Applications use attribute functions to set the operating modes and current selections for the device. The operating modes include the text and background colors; the mixing mode (also called the binary raster operation), which specifies how colors in a pen or brush combine with colors already on the display surface; and the mapping mode, which specifies how GDI maps the coordinates used by the application to the coordinate system of the device. The current selections identify which drawing objects are used when drawing output.
For more information about GDI functions, see the Microsoft Win32 Programmer's Reference.
System services are a set of functions that give applications access to the resources of the computer and the features of the underlying operating system, such as memory, file systems, and processes. An application uses system services functions to manage and monitor the resources that the application needs to complete its work. For example, use memory management functions to allocate and free memory, and process management and synchronization functions to start and coordinate the operation of multiple applications or multiple threads of execution within a single application.
System services functions provide access to files, directories, and input and output devices. The file I/O functions give applications access to files and directories on disks and other storage devices on a given computer and on computers in a network. These functions support a variety of file systems, from the MS-DOS® File Allocation Table (FAT) file system to Windows NT file system (NTFS). The network functions create and manage connections to shared resources, such as directories and printers, on computers in the network. Communications functions read from and write to communications ports as well as control the operating modes of these ports.
System services functions provide methods for applications to share resources with other applications. For example, you can make useful procedures available to all applications by placing these procedures in dynamic-link libraries. Applications access these procedures by using dynamic-link library functions to load the libraries and retrieve the addresses of the procedures. You can share useful data, such as bitmaps, icons, fonts, and strings, by adding this data as "resources" to the file for an application or dynamic-link library. Applications retrieve the data by using the resource functions to locate the resources and load them into memory.
System services functions provide access to information about the system and other applications. System information functions let applications determine specific characteristics about the computer, such as whether a mouse is present and what dimensions elements of the screen have. Registry and initialization functions let applications store application-specific information in system files so that new instances of the application or even other applications can retrieve and use this information.
System services also let applications share information with applications running on the same computer or on other computers in a network. Applications can copy information between processes by using the mailslots and pipes functions to carry out interprocess communication (IPC). For operating systems that provide security features, the security functions give applications access to secure data as well as protect data from intentional or unintentional access or damage.
System services functions provide features that applications can use to handle special conditions during execution, such as handling errors, logging events, and handling exceptions. There are features that applications can use to debug and improve performance. For example, debugging functions allow single-step control of the execution of other processes, and performance monitoring allows for detailing the path of execution through a process.
For more information about system services functions, see the Microsoft Win32 Programmer's Reference.
Multimedia functions give applications access to high-quality audio and video. Multimedia functions let you enhance and expand the capabilities of your application, giving users the ability to combine these forms of communication with more traditional forms of computer output. Using Multimedia functions, applications can create documents and presentations that incorporate music, sound effects, and video clips as well as text and graphics. The Multimedia functions provide services for audio, video, file I/O, media control, joystick, and timers.
Applications use audio functions to play and record audio data using waveform, Musical Instrument Digital Interface (MIDI), and auxiliary audio formats. When playing audio, an application can mix sounds by routing selected audio to specified devices. To ensure efficient storage of audio data, the audio functions provide access to audio compressors and decompressors through the Audio Compression Manager.
Applications use video functions to capture video clips, compress the clips, and control their playback. An application captures video clips by using simple messages to access video and wave audio acquisition hardware, such as a video tape machine, and to stream selected video clips to disk. To store video data efficiently, an application can use the video compressors and decompressors provided by the Installable Compression Manager. Applications can play back video clips either on the computer screen or on other media devices by indirectly using the Media Control Interface (MCI) through the functions of the MCIWND window class.
Applications use file I/O functions to store and retrieve the different types of multimedia data. An application can use unbuffered and buffered I/O with multimedia files, access and navigate RIFF files, and integrate custom I/O functions for multimedia data types. Of particular significance is the audio-video interleaved (AVI) file format, which provides for storing digital video clips consisting of both video and audio data. AVI is a RIFF file that has an extensible file architecture. This means an application can customize AVI files to store and retrieve nonstandard data streams.
The Media Control Interface (MCI) provides a common set of high-level commands through which applications control media devices, such as animation devices, audio CDs, digital-video devices, MIDI sequencers, video overlay devices, videodiscs, VISCA tape recorders (VCR), and waveform (digital sound) devices. To communicate with a device, an application sends messages or command strings through MCI. The corresponding device handler interprets the message or string and executes the appropriate command at the device.
Applications use joystick functions to provide support for up to two joystick devices. An application can retrieve information about a joystick, calibrate the sensitivity, and receive messages related to movement and button activity. Multimedia timer functions provide high-resolution timing for single or periodic events.
For more information about Win32 Multimedia, see the Microsoft Multimedia Programmer's Reference.
Remote Procedure Calls (RPC) give applications the means to carry out distributed computing, letting the applications tap the resources and computational power of computers on a network. Using RPC, you create distributed applications, each consisting of a client that presents information to the user and a server that stores, retrieves, and manipulates data and generally handles the bulk of the computing tasks for the client. Shared databases, remote file servers, and remote printer servers are examples of distributed applications.
A distributed application, running as a process in one address space, makes procedure calls that execute in an address space on another computer. Within the application, such calls appear to be standard, local procedure calls, but these calls invoke stub procedures that interact with the RPC run-time library to carry out the necessary steps to execute the call in the remote address space. RPC manages the network communications needed to support such calls, even the details such as network protocols. This means distributed applications need little or no network-specific code, making development of such applications relatively easy.
Microsoft RPC is just one part of a complete environment for distributed computing defined by the Open Software Foundation (OSF), a consortium of companies formed to define the components of a complete environment that supports distributed computing. Microsoft's implementation of RPC is compatible with the OSF standard with minor differences. Client or server applications written using Microsoft RPC version 1.0 will interoperate with any DCE RPC client or server whose run-time libraries implement the connection-based model and run over a supported protocol.
For more information about Remote Procedure Calls, see the Microsoft RPC Programmer's Guide and Reference.
Extension libraries give applications services and capabilities beyond the basic services of the Win32 API. The extension libraries either expand on services already provided by the Win32 API or provide unique services that are commonly used by Win32 applications. There are these extension libraries:
The common controls and common dialog boxes libraries simplify the creation and management of controls and dialog boxes. The common controls library provides predefined control windows that applications can use in dialog boxes to give the user a wider array of ways to view and input information. The common dialog boxes library provides predefined dialog boxes that applications can use to prompt the user for information needed to complete common commands, such as the Open, Save, and Print commands in the File menu.
The data decompression and file installation libraries provide useful functions for applications that install files. The data decompression library provides functions that applications use to expand files that have been compressed using the Microsoft File Compression Utility (COMPRESS.EXE). The file installation library provides functions that make it easier for applications to analyze currently installed files and install new files properly.
The DDE management and network DDE libraries simplify the process of exchanging data with other applications. The DDE management library provides functions that minimize the amount of code needed in an application to carry out dynamic data exchange and gives an application the means to exchange data without requiring user interaction. The network DDE library provides functions that applications use to connect to DDE servers on other computers in the network. These functions minimize the amount of code an application needs to access the network and ensure security across network connections.
For more information about the extension libraries, see the Microsoft Win32 Programmer's Reference.
This release of the Win32 API includes several new functions and messages. These new API elements give applications access to new, 32-bit features of the Windows 95 operating system in the areas of Window Management, Graphics Device Interface (GDI), System Services, and Extension Libraries.
Note The new Win32 functions and messages are not available on Windows NT 3.1, but will be available on all future releases of the Windows family of operating systems.
Windows 95 implements some Win32 functions and messages differently from Windows NT. If you intend to run your Win32 applications on both platforms, you need to understand these differences to help you minimize development and debugging time.
Some Win32 functions and messages, such as for security and event logging, are not supported by Windows 95. Windows 95 provides stub routines for these unsupported functions so that applications designed for other operating systems that do fully support Win32 can run on Windows 95 without errors.
Windows 95 implements some window management features in 16 bits. This imposes some restrictions on parameters in functions and messages and limits on internal storage. For example, the standard edit control is limited to somewhat less than 64K of text. In some cases, Windows 95 provides new features that can be used to avoid these restrictions and limitations, such as the rich text edit control in which the amount of text is limited only by available memory.
Windows 95 permits up to 16,364 window handles and 16,364 menu handles. Although these limits are less than under Windows NT, they are significantly greater than the limits imposed by Windows 3.1.
The wParam parameter for the SendMessageCallback, SendMessageTimeout, and SendNotifyMessage functions is limited to a 16-bit value.
Under Windows 95, the wParam parameter in list box messages, such as LB_INSERTSTRING or LB_SETITEMDATA, is limited to 16-bit values. One effect of this is that list boxes cannot contain more than 32,768 items. Although the number of items is restricted, the total size in bytes of the items in a list box is limited only by available memory. This is in contrast to the 64K data limit imposed by Windows 3.1.
Under Windows 95, the keyboard layout functions (ActivateKeyboardLayout, GetKeyboardLayoutName, LoadKeyboardLayout, and UnloadKeyboardLayout) can load only one keyboard in memory at any one time. Under Windows NT, you can have multiple keyboards in memory and switch between them. To do something similar on Windows 95 would require loading and reloading each keyboard layout as you need them.
Under Windows 95, only one desktop is available while the system runs. Although the thread desktop functions (GetThreadDesktop and SetThreadDesktop) are available under Windows 95, they don't do anything.
Any private application message must be defined above WM_USER + 0x100. This will ensure that there is no collision between private messages and dialog control messages.
Windows 95 uses a 16-bit world coordinate system and restricts x and y coordinates for text and graphics to the range ±32K. Windows NT uses a 32-bit world coordinate system and allows coordinates in the range ±2G. If you pass full 32-bit coordinates to text and graphics functions under Windows 95, the system truncates the upper 16 bits of the coordinates before carrying out the requested operation.
Under Windows 95, regions are allocated from the 32-bit heap and therefore can be as large as available memory. (In Windows 3.1, regions were limited to 64K.) All other logical objects, however, share the 64K local heap. Also, the number of region handles cannot exceed 16K. Physical objects have always existed in global memory and are therefore not limited.
Windows 95 does not support world transforms that involve either shearing or rotations. Therefore, the ExtCreateRegion function fails if the transformation matrix is anything other than a scaling or translation of the region.
Under Windows 95, pens and brushes have several limitations. The ExtCreatePen function supports solid colors only (PS_SOLID). Also, the following pen styles are supported in paths only:
PS_ENDCAP_FLAT
PS_ENDCAP_ROUND
PS_ENDCAP_SQUARE
PS_JOIN_BEVEL
PS_JOIN_MITER
PS_JOIN_ROUND
Windows 95 does not support the dashed or dotted pen styles, such as PS_DASH or PS_DOT, in wide lines. The BS_DIBPATTERN brush style is limited to an 8x8 brush.
Windows 95 does not support the CBM_CREATEDIB flag for the CreateDIBitmap function. Use CreateDIBSection to create a DIB (device-independent bitmap) instead. The CreateDIBSection function will be available in the next release of Windows NT.
For 16- and 32-bit-per-pixel DIBs, the biCompression member in the BITMAPINFOHEADER structure is set to 0 (not compressed) instead of BI_BITFIELDS if the color masks are as follows:
16bpp: Blue mask is 0x001F, green is 0x03E0, and red is 0x7C00. The high bit is not used.
32bpp: Blue mask is 0x000000FF, green is 0x0000FF00, and red is 0x00FF0000. The high byte is not used.
In such cases, the three DWORD color masks are not used. The next release of Windows NT will conform to this format. Windows 95 does not support biCompression equal to biBitFields in any drivers.
Drawing object deletion behaves slightly differently under Windows 95 than under Windows NT. Under Windows NT, if you attempt to delete a drawing object (pen or brush) while it is still selected into a DC, the DeleteObject function fails. Under Windows 95, the function succeeds but results in a nonfunctioning object. This nonfunctioning object is automatically destroyed when the DC is deleted.
When constructing a path under Windows 95, only the MoveTo, LineTo, PolyBezier, and PolyBezierTo functions are recorded.
Under Windows 95, the GetGraphicsMode and SetGraphicsMode functions support the GM_COMPATIBLE flag only. The GM_ADVANCED flag is not supported.
Although Windows 95 imposes no restrictions on the PlayEnhMetaFile and PlayEnhMetaFileRecord functions, the files and records that these functions execute are subject to the limitations described in this section. For example, the functions ignore records that attempt to draw outside the 16-bit coordinate space or that attempt to apply shearing or rotation to world
The extended error codes returned by the GetLastError function are not guaranteed to be the same under Windows 95 and Windows NT. This difference applies to extended error codes generated by calls to GDI, Window Management, and System Services functions.
Windows 95 does not support asynchronous file I/O except on serial devices. Therefore, the ReadFile and WriteFile functions fail if you pass in an overlapped region on anything other than a serial device. The GetOverlappedResult function works only on serial devices or on files opened by using the DeviceIoControl function.
Currently, the GetSystemTime function returns local time rather than UTC. In future releases, and certainly in the final product, the function will return UTC.
The precision of the time on a file on a FAT file system volume is 2 seconds. If Windows 95 is connected through a network to a different file system, the time precision is limited only by that remote device.
Under Windows NT, the DeleteFile function fails if you attempt to delete a file that is open for transforms.normal I/O or as a memory mapped file. Under Windows 95, DeleteFile deletes such files. Because deleting open files may cause loss of data and application failure, you must take every precaution to close files before attempting to delete them using DeleteFile.
Under Windows 95, shared memory mapped files, created using the MapViewOfFileEx function, appear in the same address space across all 32-bit processes in the system. If you pass in a specific base offset in the lpvBase parameter of MapViewOfFileEx and the function succeeds, you are guaranteed that the same memory region is available in every process. This is not true under Windows NT—MapViewOfFileEx fails for any process that already has the given memory region in use.
Under Windows 95, file handles that have been used to create file-mapping objects must not be used in subsequent calls to file I/O functions, such as ReadFile and WriteFile. In general, if a file handle has been used in a successful call to the CreateFileMapping function, do not use that handle unless you first close the corresponding file-mapping object.
Thread locales, retrieved and set using the GetThreadLocale and SetThreadLocale functions, are static and can be changed only at system boot time.
Under Windows 95 the FlushInstructionCache function always returns TRUE—Windows 95 supports single processor machines only.
Win32s implements some Win32 functions and messages differently than Windows NT. If you intend to run your Win32 applications on both platforms, you need to understand these differences to help you minimize development and debugging time.
Win32s relies on Windows 3.1 to provide standard dialog controls such as list boxes, combo boxes, and edit controls. Win32s translates messages between the controls and the Win32 application.
Controls have size limitations that do not exist on Windows NT. An edit control, for example, is limited to somewhat less than 64K of text; list boxes store data in one 64K heap. Therefore, a Win32 application can create a large file by way of an edit control in Windows NT and not be able to read the file back into the same edit control when the Win32 application is run with Windows 3.1.
Controls support specifying limits on the amount of information they will hold, such as EM_SETLIMIT for edit controls. One solution is to specify a lowest-common-denominator for controls to ensure compatibility across platforms. Other solutions are application-specific.
Win32s does not support EM_SETHANDLE and EM_GETHANDLE. These messages allow the sharing of local memory handles between an application and the system. In Win32s an application's local heap is 32 bits and allocated from the global heap, so Windows 3.1 cannot interpret a local handle. Text for multiline edit controls is stored in the 16-bit local heap. This means that the amount of edit control text is limited to somewhat less than 64K. To read and write multiline edit control text, an application should use the WM_GETTEXT and WM_SETTEXT messages.
Any private application message must be defined above WM_USER + 0x100. This will ensure that there is no collision between private messages and dialog control messages on Windows 3.1.
When calling the PeekMessage function, a Win32 application should not filter any messages for Windows 3.1 private window classes (button, edit, scroll bar, and so on). The messages for these controls are mapped to different values in Win32, and checking for the necessity of mapping is a time-consuming operation.
Win32s child window identifiers must be sign-extended 16-bit values. This precludes using 32-bit pointer values as child window IDs.
Windows NT dynamically grows the message queue size. Windows 3.1 has a default message queue size of 8 that can be changed by calling SetMessageQueue. This call is supported in Win32s and is a NOP on Windows NT.
SetClipboardData must be called with global handles; otherwise, the data cannot be accessed by other applications.
Applications specify the return value for the DialogBox function by way of the nResult parameter to the EndDialog function. This parameter is of type int, which is 32 bits for Win32 applications. However, this value is thunked by Win32s to the Windows 3.1 EndDialog function, which will truncate it to 16 bits. Win32s sign-extends the return code from DialogBox.
TranslateMessage has additional support on Windows NT than on Windows 3.1. Win32s provides the Windows 3.1 functionality, which is to return TRUE when any key or number is typed (which generates a KEYDOWN/KEYUP sequence). On Windows NT, function and arrow keys will also result in TranslateMessage returning TRUE. Few applications test the return value from TranslateMessage.
Resource IDs (identifiers in resource files) must be 16-bit values.
The resource table size is limited to 32K (not including the resource data).
Windows 3.1 has a limit of five cached device contexts (DCs). The GetDC call obtains a cached DC in Windows 3.1; therefore, it is important to call ReleaseDC before checking the message queue. Otherwise, another application may be scheduled and there will be one less cached DC for all applications in the system. Windows NT does not have a cached DC limit, but applications should not waste DCs. It is important to follow the GetDC/ReleaseDC model for compatibility on both platforms and good memory management.
Windows 3.1 allows drawing objects (pens and brushes) to be deleted while still selected into a DC. However, the memory allocated for the drawing object remains allocated until the process terminates. Windows NT fails the DeleteObject call. Applications should not delete selected objects or they may slowly use up system resources while the application is running on Windows 3.1.
SetDIBitsToDevice is not supported for bitmaps in memory DCs, and is limited to bitmaps of up to 2 MB when blting to the display.
Process cleanup assures that all objects allocated by an application exiting the system are destroyed and the memory freed for reuse by the system or other applications. Windows 3.1 added additional robustness and process cleanup compared to Windows 3.0, but is not as complete as Windows NT. Win32 applications running on Windows 3.1 must abide by the same rules as 16-bit Windows applications and properly free objects allocated while running, especially pens, brushes, and other graphics objects.
Windows 3.1 has a 16-bit world coordinate system. Windows NT supports a 32-bit world coordinate system. Therefore, it is necessary to use the Windows 3.1 limit in developing a Win32 graphics application that will run with both Windows 3.1 and Windows NT.
Windows NT allows Win32 applications to call SetCursor and specify an icon handle. Windows NT supports color icons and color cursors; Windows 3.1 only supports color icons and monochrome cursors. Therefore, you cannot pass an icon handle to SetCursor on Win32s.
Win32s processes that are started by Windows 3.1 applications should be launched using WinExec. The Windows 3.1 version of LoadModule will not start a Win32s process. If using the Win32 version of LoadModule, note the following difference in specifying the lpCmdLine in the LOADPARAMS32 structure passed to this function:
VirtualAlloc provides a feature on Windows NT allowing the process to request the memory allocation at a specified virtual address. This is supported on Win32s, but applications should not depend on address range that is available. Windows NT allocates memory in the low 2 GB address space; Win32s allocates memory in the high 2 GB address space. Applications can query the address space using GetSystemInfo.
Do not specify GMEM_FIXED when using GlobalAlloc. On Win32s, this will result in locked pages in memory. Therefore, allocations will be limited to physically available memory rather than virtual limits (pageable memory allocations).
The implementation of the Sleep Win32 API differs in Win32s and Windows NT. On Win32s, this function calls Yield, which will return immediately if a) no other applications have messages in their message queues awaiting processing or b) the application calling Yield still has messages in its queue. It is not possible to block for the specified delay time (as occurs on Windows NT) since Windows 3.1 is a cooperative multitasking system, not a preemptive multitasking system. Time delays should be implemented in PeekMessage loops with calls to GetSystemTime to control delay time.
On Windows NT you cannot call DeleteFile and delete a file that is open (for normal I/O or as a memory mapped file). On MS-DOS (and therefore Win32s) you can, even if SHARE.EXE is loaded. Deleting such a file may result in loss of data and application failure. Therefore, you should be very careful when using DeleteFile and must ensure that the file is not in use.
The precision of the time of a file is 2 seconds (this is an MS-DOS limitation).
GetPrivateProfileSection and GetProfileSection work only on initialization files that have unique keys. For example, in the following private initialization file:
[TestSection]
Entry1=123
Entry1=456
Entry1=789
Entry2=ABC
GetPrivateProfileSection will return three copies of the string: Entry1=123.
Windows 3.1 supports a single value (string) per key in its registration database. Windows NT supports a multivalue per key registration database and new APIs to manipulate the database. Win32s supports the subset of Win32 registry APIs that map to Windows 3.1 functionality.
Win32 applications and DLLs should be linked with 4K alignment. This is the default for the LINK32 linker that ships with the Win32 Software Development Kit (SDK). 64K alignment is supported, but 4K is more efficient for the memory manager in the shared 2 GB address space of Windows 3.1.
The WinSocket API supports blocking and nonblocking calls. The WinSocket specification indicates that blocking calls should be avoided on systems (such as Windows 3.1) that are nonpreemptive. Therefore, a portable Win32 WinSocket application should use nonblocking calls and will then run well on Win32s and Windows NT.
Windows NT supports certain NetBIOS features that are not supported on Win32s due to the nonpreemptive shared memory design of Windows 3.1. The ncb_event field of the NCB structure is ignored since Win32s does not implement Windows NT events. Also, Windows NT maintains a per-process name table; Win32s maintains one systemwide name table.
Win32s supports all multimedia sound APIs provided on Windows NT except for MIDI callbacks. Therefore, the CALL_FUNCTION flag of midiOutOpen and midiInOpen is not supported. Multimedia event callbacks (timeSetEvent and timeKillEvent) are also not supported.