Win32s was intended as an implementation of a subset of Win32, Microsoft's main 32-bit Windows API taken from Windows NT 3.1. However, several program compilation options and DLLs which were implicit in Windows NT 3.1 have to be included with the application in Win32s.
Although ostensibly compatible with early versions of Windows NT, many functions were not implemented including threading and asynchronous I/O, newer serial port functions and many GDI extensions. This essentially limits it to applications specifically designed for the platform. In addition, Microsoft made a number of changes to Win32s which were regarded by some observers as an attempt to discourage any third party from marketing a compatible platform . It would not, however, be logical for Microsoft to make developing for Win32s difficult, as it was intended to ease the transition to Win32 for developers and allow Microsoft to shift all of its own development and support to the newer platform.
At the same time, however, Microsoft already had to manage separate and sometimes incompatible APIs for MS-DOS and Win16, complicating efforts to make a third API (Win32/Win32s) a stable option for developers.
As Win32s is built on top of Windows 3.1x, it inherits many of the limitations of that environment. As a notable example, in Windows NT and Windows 95, Win32 applications execute within a private virtual address space, whereas Windows 3.x used an address space shared among all running applications. An application running on Win32s has the shared address space and cooperative multitasking characteristics of Windows 3.1. As a result of this, for a Win32 application to run on Win32s, it must contain relocation information. This is typically done by omitting the /FIXED switch or including /FIXED:NO when linking the application. By default, Visual C++ 5 and later do not generate relocation information.
A technique named thunking is fundamental to the implementation of Win32s as well as Chicago-kernel operating systems, which are Windows 95, Windows 98, and Windows Me. However, allowing user-level thunking greatly complicates attempts to provide stable memory management or memory protection on a system-wide basis, as well as core or kernel security—this allows poorly written applications to undermine system stability on Win32s, as well as the Chicago-kernel systems. The stability and security Windows NT can offer is partially based on thunking being totally illegal, except thunks from Win16 to Win32—the CPU must remain in protected mode at all times. Newer versions of Windows transparently provide a virtual machine for running Win16 applications.
Many early 1990s programs that ran on Windows 3.1 and Windows 95 used Win32s instead of completely separate 16- and 32-bit versions. Several Win32s programs that predate Windows 95 can run on it and often Windows 98. Others were purely Win16, such as Word for Windows. In theory, a "Win32s program" is just a Win32 program that uses only those Win32 calls that are available in Win32s. However, not all Win32 programs are Win32s programs, as many perfectly legal Win32 apps would not initialize at all on Win32s.
Win32s can still be found using web search engines; PW1118.EXE is generally the installation file used. Developers should ensure they are installing OLE if they require consistent clipboard handling. Many applications which need to be made OLE aware (i.e. setting up their OLE server) must be reinstalled. Win32s was also included with some early Win32 programs.
Warcraft II: Tides of Darkness, a DOS game, included a level editor that required Win32s to run. The editor used a Windows GUI for displaying the large maps because high-resolution graphic modes were already handled by Windows.