Fact-checked by Grok 2 weeks ago

Win32s

Win32s is a subsystem developed by Microsoft consisting of dynamic-link libraries (DLLs) and a virtual device driver (VxD) that enabled a subset of 32-bit Windows API (Win32 API) functionality to run on the 16-bit Microsoft Windows 3.1 and Windows for Workgroups 3.11 operating systems. It extended the existing 16-bit Windows API (Win16 API) by adding 32-bit support for key features such as multithreading, virtual memory management, structured exception handling, floating-point emulation, memory-mapped files, and named shared memory, while maintaining binary compatibility with full 32-bit Windows platforms like Windows NT. However, Win32s implemented only a portion of the complete Win32 API, with unsupported functions returning an ERROR_NOT_IMPLEMENTED error to allow graceful degradation in applications. Released initially in beta form in 1992 and with its first (1.10) in July 1993 alongside , Win32s served as a transitional technology to help extend the life of Windows 3.1x by permitting developers to create and deploy simplified 32-bit applications without requiring a full to 32-bit operating systems. Subsequent versions, including 1.20, 1.25, and the final 1.30c released in 1995, progressively expanded coverage and improved performance, particularly for memory-intensive and floating-point operations, where 32-bit apps often outperformed their 16-bit counterparts despite some overhead from thunking between 16-bit and 32-bit code layers. It supported interoperability features like (DDE), (OLE), clipboard operations, and graphics formats, but omitted advanced capabilities such as Remote Procedure Calls (RPC) and direct or interrupts, relying instead on the Win32s for . Microsoft discontinued development and support for Win32s with the advent of Windows 95 in 1995, which provided native 32-bit API support, rendering the subsystem obsolete as users migrated to fully 32-bit environments. Despite its limitations, Win32s played a crucial role in the mid-1990s software ecosystem, enabling early adoption of 32-bit programming techniques and facilitating the porting of applications from Windows NT to consumer Windows versions. It required a minimum of an Intel 386 processor and 4 MB of RAM, with a default 128 KB stack size for 32-bit processes, and was distributed as a free upgrade for Windows 3.1x users.

Development and History

Origins and Goals

In the early , identified the necessity to migrate from the 16-bit architecture of , which dominated the personal computing landscape, to advanced 32-bit systems like , all while maximizing the longevity of installed 16-bit hardware bases. Win32s emerged as a critical bridge technology, consisting of a subset of the Win32 API designed to overlay onto and deliver partial 32-bit capabilities without necessitating a full operating system replacement. This approach addressed the limitations of 16-bit environments, such as restricted memory addressing and multitasking, by introducing elements of 32-bit processing to extend the platform's viability. The was formally announced in July 1992, with a release of Win32s following in 1992 to enable early testing and developer feedback. Development of Win32s was spearheaded by Microsoft's Windows division, with collaboration from the project team to ensure alignment between the subset API and the full defined for . This effort built on the NT team's work to define a common 32-bit API standard. Strategically, Win32s aimed to empower developers to produce 32-bit applications that could reach Microsoft's vast user base, including , as the company's operating systems held around 80% of the operating system market by 1993—thereby accelerating the adoption of Win32 programming standards ahead of consumer-oriented 32-bit releases like Windows 95. A core objective was to foster binary compatibility with , allowing applications developed under Win32s to port seamlessly to the full NT environment and supporting a phased transition to without disrupting the dominant 16-bit ecosystem.

Release Versions

The development of Win32s began with a release in October 1992, distributed as part of the Windows NT SDK for developer testing and early compatibility evaluation on systems. This initial version focused on enabling basic 32-bit calls within the 16-bit environment, allowing developers to experiment with Win32 applications without full 32-bit hardware. It lacked certain components like support and was prone to instability, serving primarily as a proof-of-concept for bridging 16-bit and 32-bit code execution. The first stable release, version 1.10, arrived in July 1993 alongside , providing core stability improvements and initial support for key Win32 APIs such as those for and threading. This version marked the official launch, bundled with development tools like the Visual C++ compiler, and enabled a subset of 32-bit applications to run on 386 or higher processors under or Windows for Workgroups 3.1. Subsequent minor updates followed, including version 1.15 and 1.20 in 1994, which introduced enhancements like better 2.0 integration and bug fixes for application crashes, expanding compatibility for . Version 1.30, released in , brought significant refinements, including a help engine compatible with features and broader application compatibility through resolved issues in resource handling and emulator stability. Further patches culminated in the final official build, 1.30c (build 172), distributed in February 1996 via the installer PW1118.EXE, a approximately 2 MB in size containing core DLLs and setup files for archival and deployment purposes. ended official development and support for Win32s with Visual C++ 4.2 in late 1996, as the shift to full 32-bit platforms like and NT 4.0 rendered the subsystem obsolete for new development.

Technical Architecture

Core Implementation

Win32s operated as a subsystem extension for and 3.11, enabling the execution of select 32-bit applications within a shared 16/32-bit while preserving the underlying 16-bit operating system architecture. Unlike full 32-bit platforms such as , Win32s did not replace the core OS but extended its capabilities through layered components, allowing 32-bit code to coexist with 16-bit processes under . This approach facilitated binary compatibility for Win32 applications on legacy hardware without necessitating a complete system upgrade. At its foundation, Win32s relied on dynamic-link libraries (DLLs) and a virtual device driver () to intercept and route calls. The 16-bit WIN32S16.DLL served as the primary thunking layer, converting 32-bit parameters to 16-bit equivalents for compatibility with the Win16 subsystem, while 32-bit DLLs implemented the supported Win32 subset, handling functions like allocation and threading. The Win32s managed low-level operations, including paging and services, ensuring 32-bit applications could access extended features without disrupting the host environment. These elements collectively formed a bridge between the 32-bit application model and the 16-bit kernel. Win32s integrated directly with core Win16 components to maintain system cohesion, operating within the enhanced mode environment to enable resource sharing among mixed-mode applications in a . This setup permitted 32-bit processes to interact with 16-bit resources, such as segments, while adhering to the existing boundaries established by . Deployment of Win32s required specific hardware prerequisites to support its 32-bit extensions: a minimum 80386 for protected-mode operations and 4 MB of (with 8 MB recommended to accommodate the overhead of mixed addressing). It was compatible with both and Windows for Workgroups 3.11, though WfW 3.11 was recommended for enhanced networking and stability in settings.

API Subset and Thunking

Win32s implements its partial through a thunking mechanism consisting of user-level dynamic-link libraries (DLLs) that intercept 32-bit calls from applications and emulate them using equivalent 16-bit operations, operating entirely without kernel-mode privileges. This process involves copying parameters from the 32-bit stack to a 16-bit stack before invoking the corresponding 16-bit entry point in the underlying system, resulting in approximately 10% performance overhead relative to native 32-bit calls. The supported API subset focuses on core graphical and user interface functions, providing full implementation of the User subsystem for windowing operations and the (GDI) for graphics rendering, alongside partial support for (OLE) features such as (DDE), clipboard handling, metafiles, and bitmaps. However, advanced functionalities are excluded, including file I/O operations like CreateFile and (RPC); for these unsupported APIs, Win32s supplies stub functions that return the error code ERROR_NOT_IMPLEMENTED to maintain basic compatibility. Additionally, Win32s introduces four new APIs to facilitate the Universal Thunk (UT) mechanism, enabling communication between 32-bit executables and 16-bit DLLs. Address space management in Win32s adopts a flat 32-bit model for applications, but inherits the shared, non-preemptive address space of , limiting each 32-bit process to a maximum of 16 MB of due to constraints in the underlying 16-bit and selector limits. Win32 applications receive a dedicated 128 KB stack, with the stack pointer operating in 16:16 mode and reserving at least 8 KB for 16-bit execution during thunking operations. The binary compatibility model ensures that (PE)-format executables compiled for can execute on Win32s, provided they adhere to the supported subset and avoid restricted features; this requires executables to include relocation information in their PE headers, allowing the 16-bit loader to adjust addresses for loading at non-preferred base locations within the constrained .

Features and Capabilities

Supported Interfaces

Win32s offered support for a of the core windowing interfaces from User32.dll, enabling 32-bit applications to create, manage, and interact with windows, controls, and user input mechanisms in a manner similar to full Win32 implementations. This functionality was primarily achieved through thunking to the underlying 16-bit User subsystem, ensuring seamless UI operations within the constraints of Windows 3.1. The graphics subsystem in Win32s implemented a subset of functions from GDI32.dll, providing support for many device-independent drawing, font handling, and bitmap operations. This allowed developers to build graphically intensive applications, such as those requiring complex rendering or printing, with performance and features approaching those of , though advanced features like Bezier curves, paths, and transforms were not supported. OLE and OLEDLG integration was a key feature, supporting drag-and-drop operations, , and common dialogs for file and object manipulation. These capabilities were vital for early , enabling compound documents and data exchange between 16-bit and 32-bit components via mechanisms like , clipboard formats, metafiles, and bitmaps. Win32s also supported multithreading via APIs like CreateThread, allowing concurrent execution within the cooperative multitasking model. Win32s provided basic file I/O through Win32 APIs for synchronous read/write operations and path handling, alongside simplified registry access for key-value storage and enumeration, both without support for asynchronous modes to align with the 16-bit host environment. In version 1.30, a dedicated help engine was added to handle .hlp files in the style used by , improving documentation support for 32-bit applications.

Memory and Resource Handling

Win32s employed a 16/32-bit approach to memory and resource handling, bridging the limitations of the environment with partial 32-bit functionality. This design allowed 32-bit applications to execute within the existing 16-bit kernel's , but it imposed constraints derived from the underlying system's shared and lack of . Developers had to navigate these mechanics carefully, as the subsystem did not provide the full protections or per-process of native 32-bit Windows platforms. The multitasking model in Win32s directly inherited the nature from Win16, requiring applications to explicitly yield —typically through calls like GetMessage—to enable switching between tasks. Unlike preemptive systems, Win32s offered no automatic scheduling intervention, meaning a single misbehaving application could halt the entire system by failing to relinquish the CPU. Thread support existed but operated within this framework, without dedicated priority mechanisms to favor certain threads over others, limiting fine-grained over execution. Resource management emphasized global heaps shared across DLLs and processes, a necessity stemming from Win32s's unified address space. All DLLs loaded into the system shared data segments, so modifications by one process were immediately visible to others, demanding manual to prevent race conditions or inconsistencies. Heaps for dynamic allocation were tied to individual processes, but the interconnected structure required explicit tracking of allocations and deallocations to mitigate leaks, as automatic collection or per-process cleanup was unavailable. This manual oversight was critical in multi-DLL scenarios, where shared resources could persist beyond a single application's lifecycle. Memory protection was absent in Win32s, as 32-bit code executed in user mode alongside 16-bit components within the same , without barriers to isolate faults. A violation or invalid pointer in a 32-bit application could corrupt shared resources or trigger a , potentially crashing the entire session rather than isolating the issue to the offending process. This vulnerability underscored Win32s's role as a rather than a robust 32-bit , prioritizing over stability.

Compatibility and Usage

Application Support

Win32s enabled the execution of select 32-bit applications on 16-bit Windows environments, provided they were designed to be "Win32s-aware," meaning they adhered to the runtime's constraints such as avoiding calls to unsupported APIs or excessive resource demands. Among games and utilities, notable examples include , a 32-bit title bundled with that could run on Win32s with variable stability depending on the version. , included as a test application in Win32s 1.30c, operated reliably as a simple leveraging basic Win32 interfaces. The Warcraft II level editor, a utility tool from , was another success, allowing users to create custom maps on Win32s-equipped systems without requiring full features. In productivity and web browsing, early versions of , such as 1.0 and 1.5, supported Win32s for 32-bit operation on x, enabling basic web navigation though later iterations like IE 2.0 shifted to 16-bit for broader compatibility. NCSA Mosaic 2.0, one of the pioneering graphical web browsers, required Win32s to run its 32-bit executable on , facilitating early Internet access for users on legacy hardware. Prototypes and early builds of , the lightweight word processor from , could execute on Win32s by including necessary DLLs in the system directory, though with limitations like instability in file operations. For compatibility, applications had to remain within Win32s's 16 MB per-process memory limit and eschew advanced features like , which lacked native support; full DirectX-dependent games, such as those using for accelerated graphics, typically failed to launch or crashed due to missing APIs. In modern contexts, experiments in 2020 demonstrated the potential to run C# applications on Win32s via the CoreRT runtime for and the 1994 Visual C++ linker, compiling managed code into native executables compatible with Windows 3.11 environments.

Development Tools

Microsoft's primary development tools for Win32s were provided through the Win32 SDK, which was bundled with Visual C++ versions 1.0 through 4.1. These releases included specialized headers and libraries for the Win32s API subset, allowing developers to create 32-bit applications compatible with the environment. The integration of the SDK into the Visual C++ IDE facilitated a seamless for , compiling, and code targeting Win32s. Third-party vendors extended support for Win32s development. Borland C++ 4.x, released from 1993 to 1995, offered built-in targeting for Win32s, enabling unified development across , 16-bit Windows, Win32s, and platforms from a single codebase. Symantec C++ also provided comprehensive support for Win32s, with features particularly advantageous for embedded development scenarios. Developers verified the functionality of their tools and implementations by running sample applications like , a 32-bit game bundled with Win32s installations to test core calls and subsystem integrity post-setup. Building Win32s executables required linkers from the mid-1990s era, such as the Linker included in Visual C++ 2.0 (1994), to generate (PE) files with essential relocation data for within the 16-bit host's constraints. These linkers handled the PE format specifics, including base relocations, to ensure compatibility without relying on full 32-bit OS features.

Limitations and Constraints

Functional Restrictions

Win32s, as a subset of the designed to run on 16-bit , imposed significant functional restrictions that prevented it from achieving full with the complete Win32 found in . These limitations stemmed from the underlying architecture of Windows 3.x, which lacked native support for advanced 32-bit features, forcing Win32s to emulate them within constrained boundaries. Applications targeting Win32s had to be specifically designed or adapted to avoid unsupported functionalities, often requiring developers to use conditional or checks to ensure compatibility. One major restriction was the absence of multi-threading support, as Win32s did not implement the Win32 threading APIs such as CreateThread or the associated primitives. All execution occurred within a single-threaded context, limiting applications to sequential processing and preventing concurrent task handling that was standard in full Win32 implementations. Similarly, operations, including overlapped I/O via functions like ReadFileEx and WriteFileEx, were not supported, forcing applications to rely on synchronous blocking calls that could degrade performance in I/O-intensive scenarios. Advanced GDI features, such as font scaling and outline rendering at arbitrary sizes, were also unavailable; Win32s provided only basic rasterized support without the precision scaling or hinting mechanisms of later systems, resulting in potential visual inconsistencies on different displays. Win32s offered no support for DirectX APIs, including for 2D graphics acceleration or for 3D rendering, confining graphics operations to the standard GDI and restricting and gaming applications to software-based rendering. Security features like security descriptors, which define access control lists (ACLs) for objects, were absent, as Win32s operated in a flat security model inherited from Windows 3.x without NT-style . Kernel-mode drivers could not be loaded or executed; all driver interactions were limited to user-mode VxDs ( drivers) under the Windows 3.x model, preventing applications from accessing low-level or system services that required privileges. Binary compatibility added further constraints, requiring executable files (EXEs) to include relocation information in their (Portable Executable) headers to allow dynamic address fixing during loading, as Win32s shared a single linear with 16-bit components. This made Win32s incompatible with (PIC), which relies on relative addressing without fixed base locations, as the loader could not handle relocatable code without explicit relocation tables. Consequently, developers had to compile applications with relocation support enabled, increasing file sizes and complicating optimization. Due to the lack of process isolation in the shared address space of Windows 3.x, Win32s applications ran without protected boundaries, exposing the entire system to faults; a single application error could corrupt global memory or cause system-wide crashes. This vulnerability was particularly evident in early beta versions, where instability led to frequent general protection faults (GPFs) and required extensive fixes in subsequent releases to mitigate global crashes from unhandled exceptions or memory overflows. For instance, in Win32s was restricted to a maximum of 256 MB total linear , often leading to out-of-memory conditions under load without the per-process of full Win32. Win32s also lacked support for Unicode APIs, relying on ANSI character sets, and provided only basic support without full DCOM capabilities, further limiting and features.

Installation and Stability Issues

Win32s version 1.30, the final release, is installed by downloading the self-extracting archive PW1118. from official archives or reputable software preservation sites such as WinWorldPC, where beta versions and verification checksums like SHA512 are available for authenticity checks. The process requires running in 386 enhanced mode; users create a temporary directory, extract the archive by executing PW1118., close all applications, and then launch SETUP. to complete the . For full support, including 2.0 functionality, the installation bundles OLE2.DLL, though developers must ensure proper integration if using advanced features. Despite these steps, installation could fail due to common pitfalls such as insufficient disk space, conflicting drivers, or prior incomplete setups; troubleshooting involves deleting residual files like W32SYS.DLL and WIN32S16.DLL before retrying. Post-installation verification is recommended using simple diagnostic tests, such as running the included game, which exercises core Win32s components; also provided utilities in the Win32 SDK for checking subsystem integrity. Runtime stability posed significant challenges, with frequent General Protection Faults (GPFs) arising from thunking errors, where 32-bit calls were translated to 16-bit equivalents, often leading to access violations in resource-constrained environments. In Windows for Workgroups setups, compatibility issues frequently necessitated updates to VMM.VXD, the manager, to prevent crashes during protected-mode operations. Additional conflicts occurred with third-party or managers like QEMM, which interfered with Win32s's drivers, requiring users to disable or replace them for reliable operation.

References

  1. [1]
    Q83520 - General Overview of Win32s
    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 ...
  2. [2]
    Win32s Frequently Asked Questions - MIT
    Microsoft Win32s Upgrade -- Version 1.30c. This file contains the latest version of Win32s to allow you to run Win32-based applications under Windows 3.1 or ...<|control11|><|separator|>
  3. [3]
    Undocumented Windows
    ... Win32s, Microsoft's planned "subset" of. Win32 that will run right on top ofWindows 3.1. The Win32 API is mentioned in various places throughout this book ...
  4. [4]
    https://bitsavers.trailing-edge.com/pdf/microsoft/windows_3.1/Schulman_-_Undocumented_Windows_1992.pdf
  5. [5]
    David Cutler - CHM - Computer History Museum
    In 1988 Cutler joined Microsoft to lead the development of a portable operating system for personal computers that could run on many different computer ...
  6. [6]
    Computer industry luminaries salute Dave Cutler's five-decade-long ...
    Apr 15, 2016 · Cutler stopped managing the entire NT project in 1996, but continued to lead the kernel development until 2006. In March 2005, he completed one ...
  7. [7]
    Microsoft Confronts Its Success - The New York Times
    Aug 23, 1993 · Yet Microsoft, which controls almost 80 percent of the market for personal computer operating systems, and which was investigated by the F.T.C. ...
  8. [8]
    Win32s version tour… - Virtually Fun
    Apr 4, 2011 · For anyone that wants to play with it, the 1992 version of Win32s is available here. The next, and final beta from March of 1993. This one does ...Missing: date | Show results with:date
  9. [9]
    Win32s 1.1 - WinWorld
    Release date: 1993; Minimum CPU: 386; User interface: GUI; Platform: Windows; Download count: 36 (4 for release). Downloads. Download name, Version, Language ...
  10. [10]
    Win32s 1.20 - WinWorld
    Product type: System ; Vendor: Microsoft ; Release date: 1994 ; Minimum CPU: 386 ; User interface: GUI ...
  11. [11]
    Win32s 1.30 - WinWorld
    Win32s (Win32 subset) was an API layer for Windows 3.1 and Windows for Workgroups that allowed some Win32 applications that compiled with the subset of Windows ...
  12. [12]
    FILE: Microsoft Win32s Upgrade - MIT
    MORE INFORMATION. The following file is available for download from the Microsoft Software Library: Pw1118.exe. Release Date: Feb-22-1996. For more information ...
  13. [13]
    BEARWINDOWS - Microsoft Windows 3.1x/WfW + Win32s
    Microsoft Win32s version 1.30c is the latest version of the software that allows you to run Win32-based applications on Windows version 3.1 or Windows for ...
  14. [14]
    Microsoft® Visual C++ Version Information
    This document lists brief descriptions of current and older MS-C++ development tools for the PC, along with notes and a brief list of features.
  15. [15]
    General Overview of Win32s (83520)
    ... Win32s Programmer's Reference" and by querying for Knowledge Base articles on "Win32s ... shared address space, while Windows NT runs them preemptively in ...
  16. [16]
    PRB: Page Fault in WIN32S16.DLL Under Win32s (115082)
    Start two instances of the Win32 application under Win32s. Close one instance, then close the other instance. A page fault is generated in WIN32S16.DLL.Missing: WIN32S32. | Show results with:WIN32S32.
  17. [17]
    Will It Run Windows? - Low End Mac
    Oct 23, 2001 · Win32s requires at least Windows 3.1 running on a 386. Windows 95. Windows 95 will run on as low-end a PC as a 386SX with 4 MB of RAM, but you ...
  18. [18]
    How Discord Was Ported To Windows 95 And NT 3.1 - Hackaday
    Jun 17, 2025 · Win32s does not provide more than 16 MB of memory for each application, and you are limited by the global GDI and USER resource limits. ... MAX ...<|control11|><|separator|>
  19. [19]
    PE Format - Win32 apps - Microsoft Learn
    Jul 14, 2025 · This specification describes the structure of executable (image) files and object files under the Windows family of operating systems.
  20. [20]
    If Windows 3.11 required a 32-bit processor, why was it called a 16 ...
    May 17, 2010 · A Win32s application ran in the same virtual machine as the rest of Standard mode Windows, but when it ran, the CPU really was in 32-bit ...<|control11|><|separator|>
  21. [21]
    Under the Hood: Happy 10th Anniversary, Windows | Microsoft Learn
    Win32 DLLs implicitly have their data area in per-process memory. Each DLL starts out with a fresh new copy of its data section when a new process loads the DLL ...
  22. [22]
    TN058: MFC Module State Implementation - Microsoft Learn
    Aug 2, 2021 · ... Win32s DLL model. In Win32s all DLLs share their global data, even when loaded by multiple applications. This is very different from the ...
  23. [23]
    The Win32s compatibility list
    Considering its 1995 release date (and 32 bit nature), it isn't all that amazing that Windows NT 3.51 is more demanding than plain 3.1x: 16 MB of RAM are ...<|control11|><|separator|>
  24. [24]
    List of Win32s games - PCGamingWiki PCGW
    Jun 25, 2025 · This is an auto-generated list of games known to support 16-bit versions of Windows by running specially compiled 32-bit executables using the Win32s runtime ...Missing: applications utilities
  25. [25]
    Internet Explorer 1 - BetaWiki
    Version, 1.0 ; Compatible with, Windows 95 RTM · Windows 3.1x (using Win32s) ; Release date, 1995-08-24 ; Replaced by, Internet Explorer 1.5 (Windows 3.1x)
  26. [26]
    readme.txt
    The latest version of Win32s is available from NCSA's FTP site, ftp.ncsa.uiuc.edu, in the /Mosaic/Windows directory. The file w32sOLE.exe is a self-extracting ...
  27. [27]
    Windows 95 Programs in Windows 3.1 x - VOGONS
    Jun 15, 2024 · Place the DLLs next to WORDPAD.EXE or in the WINDOWS\SYSTEM\WIN32S directory. Now, if you try running WordPad you'll get this: “Could not load ...
  28. [28]
    DirectX and Win32s + Windows 3.1? - Google Groups
    Hi! Does anybody know is Win32s+win3.1 support DirectX technology? Our company had developed game, that use DirectX. We want to
  29. [29]
    Microsoft boffin inadvertently highlights .NET image woes by running ...
    Jan 22, 2020 · Success in this case hinges on the use of CoreRT, described as an "experimental .NET Core runtime optimized for AOT (ahead of time compilation)" ...
  30. [30]
    INFO: General limitations under Win32s (131896)
    This article describes some of the known limitations in the implementation of certain features under Win32s. The information in this article does not ...
  31. [31]
    Synchronous and Asynchronous I/O - Win32 apps | Microsoft Learn
    Jul 8, 2025 · There are two types of input/output (I/O) synchronization: synchronous I/O and asynchronous I/O. Asynchronous I/O is also referred to as overlapped I/O.Missing: Win32s | Show results with:Win32s
  32. [32]
    Security Descriptors - Win32 apps - Microsoft Learn
    Jul 9, 2025 · A security descriptor contains the security information associated with a securable object. A security descriptor consists of a ...
  33. [33]
    Win32s for the Microsoft Windows 3.1x Operating System
    ### Summary of Win32s Installation and Requirements
  34. [34]
    How to Troubleshoot Win32s Installation Problems - MIT
    May 21, 1998 · Win32s requires Win32s.exe and Win32s16.dll to run. Reinstall Win32s ... dll, and Win32s.exe from your hard drive before installing.