Taken from MS's review of Chicago (Win95) design choices:
"Support for Win16–based Applications
16-bit Windows–based applications (Win16) run together within a unified address space, and are run in a cooperatively multitasking fashion as they do under Windows 3.1. Win16–based applications benefit from the preemptive multitasking of other system components including the 32-bit print and communications subsystem, and the improvements made in system robustness and protection from the Chicago system kernel.
When Win16–based application support was examined by the Chicago development team, three goals drove the architectural design based on customer needs, resource needs, and market needs: compatibility, size, and performance. Functionality such as running Win16–based applications together in the Win16 subsystem preemptively or running Win16–based applications in separate VMs was examined, however each option examined failed to meet the design goals set forth. The following discussion will provide some insight as to the architecture design of Chicago for running Win16–based applications in a fast, stable, and reliable way.
First and foremost, Chicago needs to run existing Win16–based applications without modification. This is extremely important to existing customers that want to take advantage of new functionality offered in Chicago such as 32-bit networking, but don’t want to have to wait until new Chicago-enabled applications are available on the market.
Chicago builds upon the Windows 3.1 platform to provide support for running existing Win16–based applications and using existing Windows–based device drivers, while providing support for the next generation of 32-bit applications and components. Chicago extends the Windows 3.1 architecture in areas that have little or no impact on compatibility, as well as enhances the architecture to deliver a faster, more powerful 32-bit operating system.
While many newer computer purchases are Intel 80486-based computers with 4MB or 8MB (or more) of memory, there are still a high percentage of 80386DX-based computers with 4MB of memory in use running Windows 3.1 today. To support the needs of the market, Chicago needs to run on a base platform of an Intel 80386DX-based computer with 4MB of RAM, to provide access to the new features and functionality provided, without requiring an upgrade of existing hardware or the addition of more RAM.
To meet its design goals, the Chicago development team designed Chicago to occupy no more working set than Windows 3.1 currently does, thereby insuring that any Win16–based application running at a perceived speed on a 4MB or 8MB computer (or greater) still runs at the same (or higher) speed under Chicago and does not suffer any performance degradation. To meet the required size goals of Chicago, Win16–based applications run within a unified address space, resulting in little overhead beyond that required by Windows 3.1 to support running Windows–based applications. This allows Chicago to not only simply fit on a 4MB computer, but also to perform well. The Chicago architecture includes innovative design features such as dynamically loadable VxDs to decrease the working set of components and memory requirements used by the operating system.
Meeting the size design goal (as well as to meet the compatibility goal), precluded the development team from adopting a strategy of running Win16–based applications in a separate VM by running a separate copy of Windows 3.1 on top of the operating system (thereby paying a several megabyte “memory tax” for each application) as OS/2 does, or emulating Windows 3.1 on top of the Win32 subsystem (thereby paying a "memory tax" for running Win16–based applications) as Windows NT does.
Running Win16–based applications in separate VMs is very expensive memory wise. This would require separate GDI, USER, and KERNEL code in each VM that is created, requiring the working set to increase by as much as 2MB for each Win16–based application that is running (as is required by OS/2 for Windows). If you have a computer with 16MB or more, this may not appear to be such a big deal. However, given the existing installed base of computers it would be impossible to run Win16–based applications in their own separate VMs in 4MB at all, and very difficult to run them in 8MB with the same level of performance as customers observe and expect under Windows 3.1 today.
Users expect their existing Win16 applications to run as fast or faster than they do under Windows 3.1. Win16–based applications will benefit from the 32-bit architecture of Chicago including the increased use of 32-bit device driver components and 32-bit subsystems, as will MS-DOS–based applications.
Win16–based applications run within a unified address space and interact with the system much as they do under Windows 3.1 today. Running Win16–based applications in separate VMs requires either a mapping of Win16 system components in each address space, as Windows NT does, or providing a separate copy of each system component in each address space, as OS/2 for Windows does. The additional memory overhead required for Win16 system components in each VM to run a Win16–based application has a negative impact on system performance.
Chicago balances the issue of system protection and robustness, with the desire for better system performance and improves on the system robustness over Windows 3.1. The improvements in this area are briefly discussed below, and are described in greater detail in a separate section of this guide.
The support for running Win16–based applications provides protection of the system from other running MS-DOS–based applications or Win32–based applications. Unlike Windows 3.1, an errant Win16–based application can not easily bring down the system or other running processes on the system. While Win32–based applications benefit the most from system memory protection, the robustness improvements present in Chicago result in a more stable and reliable operating environment than Windows 3.1.
Win16–based applications run within a unified address space, and cooperatively multitask as they do under Windows 3.1. The improvements made to overall system-wide robustness greatly enhance the system’s ability to recover from an errant application, and lessens the likelihood of application errors due to improved clean up of the system. The occurrence of general protection faults (GPFs) under Windows 3.1 are most commonly caused by an application that writes over its own memory segments, rather than being caused by an application overwriting memory belonging to another application. Windows 3.1 did not recover gracefully when a Windows–based application crashed or hung. When an application was halted by the system due to a GPF, the system commonly left allocated resources in memory, causing the system to degenerate.
Due to improved protection in Chicago, an errant Win16–based application can not easily bring down either the system as a whole, or other running MS-DOS or Win32–based applications, and can at most impact other running Win16–based applications.
Other protection improvements include the use of separate message queues for each running Win32–based application. The use of a separate message queue for the Win16 address space and for each running Win32–based application provides better recovery of the system and doesn’t halt the system should a Win16–based application hang.
System robustness is also greatly improved when running Win16–based applications over Windows 3.1. Chicago now tracks resources allocated by Win16–based applications and uses the information to clean up the system after an application exits or ends abnormally, thus freeing up unused resources for use by the rest of the system.
Robustness improvements is discussed later in a separate section of this guide."