Download Low-level design features explain why OS/2 Warp, Windows 95

COVER STORY
Operating Systems
Your Next OS
Architectural
Review
Low-level design features explain why
OS/2 Warp, Windows 95, Windows NT, and
Windows 3.1 differ so significantly.
By Thomas Mace
Today, it’s easy to find fault with the Microsoft Windows 3.x architecture, which
was laid down when 286 processors and
small amounts of RAM were the norm.
But it’s also worth recalling what Windows 3.x brought to the PC: a sophisticated GUI, transparent memory management, scaleable fonts and a unified
imaging model, multitasking, and 32-bit virtual device drivers (VxDs)—just
to name the most important
contributions. Here, we
look at the architectural
pros and cons of Windows
3.1x and the 32-bit operating systems poised to succeed it.
WINDOWS 3.1 X
Fundamentally, Windows 3.1x has a 16bit design. Its kernel, most major system
components, and native applications are
largely implemented in 16-bit code. (Its
little-used Win32s API supports 32-bit
apps, but it doesn’t support threading.)
All native Windows 3.1x applications
and all of Windows’ own system DLLs
are mapped into a common segmented
virtual address space, 4GB in size. All
these components are visible to (and
often writable by) each other. At the bottom of this address space, usually below
the 1MB mark, are the real-mode device
drivers that provide an interface to peripheral subsystems such as video cards
or printers. Windows 3.11
does use VxDs for the file
system, providing a protected-mode path to disk.
This stripped-down design provides a very small
working set, (the application and system code that
must be loaded for any
given task), so Windows
3.1x can run well on systems with limited
RAM. It also allows for very efficient
code execution, since programs can call
API functions from within their own
memory space. Its drawback is a lack of
protection when something goes wrong.
Since programs and system components
are visible to each other, a buggy program can easily overwrite memory belonging to another process. While Win-
COVER STORY
Operating Systems
dows 3.1x is capable of recovering from
some of these general protection faults
(GPFs), the outcome is often a systemwide crash.
Windows 3.1x runs multiple applications through a simple scheduling mechanism called cooperative multitasking.
Under this system, each application is responsible for voluntarily giving up control
when it checks its message queue and
finds it empty. But if an application fails to
check its message queue, either because it
is busy or because it hangs, other applications are kept from their share of OS resources.
Another frustration Windows 3.1x
users have long faced is the limited size of
GDI and USER resources. These constraints are due to the fact that the GDI
and USER system DLLs use several 64K
heaps for storing a variety of arcane data
structures created by running applications. When these small heaps fill up, you
see an out-of-memory error even with
plenty of free memory left.
WINDOWS 95
Windows 95 represents an evolutionary
development of Windows 3.1x rather than
a clean break with the past. While it
Comparative OS Architectures: The memory model of each operating
WINDOWS 3.1
WINDOWS 95
Windows 3.1 embodies trade-offs between performance and protection that hark
back to the days of the 286. While it provides good performance for Win16 applications, DOS applications, real-mode device drivers, and virtual device drivers (VxDs),
it offers almost no protection against badly behaved applications.
Windows 95 strikes a balance among performance, compatibility, and robustness.
It offers fast execution of Win32, Win16, and DOS applications, and it can use realmode device drivers. While it offers better crash protection than Windows 3.1, it
remains vulnerable on several fronts.
The segmented memory space of a Win16
application is visible to and addressable by all
other Win16 applications. Operating-system
kernel DLLs and VxDs are also visible to all
applications. This design, where a single pool
of memory is shared among applications and
the OS, provides fast performance as API calls
to system DLLs do not entail ring transitions
or context switches. The clear disadvantage is
that any application can scribble on memory
belonging to other applications or operatingsystem components, potentially bringing
down the whole system.
Win16 applications are cooperatively
multitasked. Under this system, the application, rather than the operating system, is
responsible for giving up control to the next
application. A crashed or misbehaving
program can keep all others from receiving
system resources.
Addresses between 2GB and 4GB are mapped
into the address space of each Win32 application and are shared by all processes.
Addresses between 3GB and 4GB contain the
Ring 0 components, including virtual device
drivers (VxDs), the virtual machine management subsystem, and the file management
subsystem. This memory area is visible to and
writable by Win32 apps.
Addresses between 2GB and 3GB contain all
Ring 3 Windows system DLLs, such as Kernel,
GDI, and User, as well as any Win16 applications.
All 16-bit Windows applications run here
in a shared address space, where they are
cooperatively multitasked. This virtual 16-bit
Windows machine is subject to the same
vulnerabilities as Windows 3.1.
Between 4MB and 2GB, each Win32 app sees
a private flat address space; it cannot see any
other Win32 processes. Errors occurring here
can usually be trapped without bringing down
the operating system.
Addresses from 0 bytes to 4MB are shared by
all processes. This is required for compatibility with real-mode device drivers, TSRs, and
some 16-bit Windows applications, but
makes it possible for any process to corrupt
components residing in those addresses.
While the first 64K is not addressable by
Win32 applications, it can be addressed and
potentially corrupted by 16-bit applications.
system a
rating
COVER STORY
Operating Systems
brings many significant changes to the 16bit Windows architecture, it also keeps
some of its essential features. The result is
a hybrid OS, one that can run 16-bit Windows and DOS legacy apps and older
real-mode device drivers while supporting true 32-bit applications and 32-bit
VxDs.
The most important improvements
Windows 95 brings include native sup-
port for 32-bit multithreaded applications, protected address spaces, preemptive multitasking, far more extensive and
efficient use of VxDs, and increased use
of 32-bit heaps for storing systemresource data structures. Its most significant drawback is that it is still relatively
unprotected from badly behaved applications.
Each native Windows 95 application
sees a flat 4GB address space containing
itself plus the Windows 95 system code
and drivers. As far as each 32-bit application is concerned, it is the only application on the PC. The application code
loads into this address space from the
4MB to the 2GB mark. Although 32-bit
apps can’t see each other, they can pass
data to each other via the Clipboard,
DDE, and OLE. All 32-bit applications
system as seen from the application’s point of view.
OS/2 WARP
OS/2 Warp offers good performance of native OS/2, 16-bit Windows, and DOS
applications while delivering better crash protection than either Windows 95 or
Windows 3.1. Because of this, however, it is not compatible with DOS and Windows device drivers. It does not support Win32 applications.
OS/2 system code is mapped into the address
range between 512MB and 4GB. As in
Windows 95, this address space is mapped
into and shared by all 32-bit processes. The
advantage is that many API calls can be
serviced by system code without a costly
context switch. The disadvantage is that
some system components are exposed to
overwriting by malicious applications,
causing a systemwide crash.
Each native 32-bit OS/2 application sees a flat
address space from 0 bytes to 4GB; the
application itself is mapped into the first
512MB. An application does not see other 32bit OS/2 applications, although it can communicate with them via cut-and-paste or OS/2
DDE. Native applications and system components are preemptively multitasked at the
thread level.
Win16 applications can run either in separate
Windows VMs or in a common Windows VM.
Depending on the version of Warp, the Windows code is provided as system DLLs or by an
actual copy of Microsoft Windows 3.1. Separate Windows sessions are preemptively
multitasked with other applications. Win16
applications in the common Windows VM are
cooperatively multitasked and are unprotected
from each other, as in Windows 3.1. OS/2 sees
Windows VMs as native 32-bit processes.
WINDOWS NT
Windows NT’s client/server architecture offers significantly better crash protection
than OS/2 or Windows 95. But you’ll need a powerful PC with ample memory to get
acceptable performance. Windows NT supports Win16 and DOS applications but
does not support real-mode device drivers.
Windows NT preemptively multitasks Win32
apps at the thread level. It can execute Win16
applications cooperatively in a shared
memory space or preemptively in separate
memory spaces for better protection.
The address space from 2GB to 4GB contains
low-level Ring 0 system kernel code. System
pages are not visible to applications.
Each Win32 application sees a flat 2GB
address space. The app itself is mapped into
the region between 64K and 2GB. The first
64K of memory is nonaddressable.
The upper region of this
application space contains
what appear to the application as the Ring 3 system
DLLs. These are in fact proxy
stub forwarders called
client-side DLLs. When the
application calls an API
function, the client-side DLL
passes the call to a separate
system-server process.
The system server runs in an
address space that is
invisible to the Win32
application. Here the call
parameters are validated and the true system
code executes. This design results in a high
degree of security, but the ring transitions and
context switches required create significant
overhead.
COVER STORY
Operating Systems
are preemptively multitasked on a perthread basis. The thread scheduler, a part
of the virtual memory management
(VMM) system, distributes system time
among the pool of current threads based
on each thread’s priority level and readiness to run. Preemptive scheduling offers
far smoother and more robust multitasking than the cooperative method used in
Windows 3.1x.
The Windows 95 system code resides
above the 2GB mark. In the range of 2GB
to 3GB are the Ring 3 system DLLs and
any DLLs that are used by multiple programs. (Intel 32-bit processors offer four
hardware-enforced protection levels
named Ring 0 through Ring 3. Ring 0 is
the most privileged.) Windows 95’s Ring
0 components are mapped from 3GB to
4GB. These important, highly privileged
pieces of code include the VMM subsystem, the file system, and VxDs.
The area of memory from 2GB to 4GB
is mapped into the memory space of every
32-bit application so it is shared by all 32bit apps on your PC. This design allows
API calls to be serviced directly within the
application’s address space, and it limits
the size of the working set. The downside
is compromised robustness. There is
nothing to stop a buggy application from
scribbling on addresses belonging to system DLLs, crashing the entire show.
The area from 2GB to 3GB also contains any 16-bit Windows applications
you may be running. For compatibility
reasons, these execute in a shared address space, where they can corrupt each
other just as they can in Windows 3.1x.
The memory addresses below 4MB
are also mapped into the address space
of each application and are shared by all
processes. This makes compatibility
with existing real-mode device drivers
possible, since they require access to
those addresses. It also opens up another area of the memory map to malicious
scribbling. The very bottom 64K of this
address space is not addressable by 32bit applications, in order to catch faulty
pointers, but it is addressable by potentially buggy 16-bit applications.
Some Windows 95 system DLLs,
USER and GDI in particular, still con-
1/2 horizontal ad
tain 16-bit code. One unfortunate result
of this is that USER’s and GDI’s 64K
local heaps and their attendant systemresource limitations are still with us. Fortunately, Windows 95 did move a number
of data structures into 32-bit heaps, making it far harder to run out of system resources than under Windows 3.1x. Another problem raised by 16-bit system
code is the Win16Mutex effect. Since 16bit system code is nonreentrant, only one
thread can access 16-bit DLL functions
at a time, potentially hobbling other
processes that need access to the DLL in
question.
OS/2 WARP
OS/2 Warp Connect 3.0 is architecturally
similar to Windows 95 in many ways,
though its design philosophy makes fewer
compromises with 16-bit legacy code. The
result is a better-protected OS than Windows 95 that can run OS/2, Win16, and
DOS programs, but that is incompatible
with 16-bit Windows device drivers. OS/2
Warp doesn’t support 32-bit Windows apps.
Native 32-bit OS/2 applications see a
COVER STORY
Operating Systems
4GB private address space. Application
code is mapped into the range from 0 to
512MB while the OS/2 system code is
mapped from 512MB to 4GB. This system code area is shared by all processes.
Executing 32-bit apps do not see each
other although they can communicate via
cut-and-paste or OS/2 DDE. OS/2 Warp
preemptively multitasks native applications on a per-thread basis.
This design provides many of the same
benefits and drawbacks found in Windows 95. System resources are allocated
smoothly, and calls to system APIs can be
serviced without costly overhead, since
the system DLLs are in the same address
space as the calling application. The
working set is also kept to a reasonable
size, since multiple instances of system
DLLs are not required. But protection is
not guaranteed because badly behaved
applications can still overwrite important
system areas.
OS/2 Warp does go beyond Windows
95 in important ways, however. Problems
with system-resource limitations are unknown, since OS/2 Warp does not use
64K heaps to store system DLL data
structures. It also provides several services unknown to Windows including the
System Object Model (SOM) and REXX,
a powerful batch language used on a wide
variety of IBM platforms.
In addition to hosting native OS/2 applications, OS/2 Warp can run 16-bit Windows apps. Depending on which version
you buy, OS/2 Warp does this either by
running a copy of Microsoft Windows 3.1
as a process under OS/2 or by running its
own Win-OS/2 libraries. With either, you
have the choice of running a Windows
session for each Windows program or
running all Windows programs in a
shared address space. The latter approach
may offer better compatibility but
promises less stability, since it functions
essentially like Windows 3.1x. OS/2 Warp
can also run DOS applications in highly
configurable, preemptively multitasked
DOS virtual machines.
OS/2 was not architected to support
real-mode device drivers, so your hardware devices must be natively supported
by OS/2 drivers. The advantage to this ap-
1/2 horizontal ad
proach is that OS/2 can fully protect the
first 4MB of the application memory map,
an area where Windows 95 remains vulnerable to crashes.
WINDOWS NT WORKSTATION
Windows NT Workstation 3.51 is essentially a server operating system optimized
for workstation use. This explains an architecture where absolute protection of
applications and data take precedence
over speed and compatibility considerations. Windows NT’s extreme robustness
comes at the price of high system overhead, so a fast CPU and at least 16MB of
RAM are needed for acceptable performance. Like OS/2 Warp, Windows NT
achieves low-memory security at the
price of being incompatible with realmode device drivers. Windows NT runs
native 32-bit NT applications and most
Windows 95 applications, too. Like Windows 95 and OS/2 Warp, Windows NT
can also host 16-bit Windows and DOS
applications.
The design of Windows NT’s memory
map is strikingly different from those of
COVER STORY
Operating Systems
Windows 95 and OS/2 Warp. Native applications see a private 2GB address space
running from 64K to 2GB (the first 64K is
fully nonaddressable). Applications are
invisible to each other, though they can
communicate via the Clipboard, DDE,
and OLE.
At the top of each 2GB application
space are what appear to the application
as Ring 3 system DLLs. In fact, these are
merely proxy stub forwarders called
client-side DLLs. When the application
calls most API functions, the client-side
DLL issues a Local Process Communication (LPC), which passes the call and associated parameters to an entirely separate address space that contains the true
system code. This server process performs
parameter validation, executes the requested function, and passes the results
back into the application’s memory space.
Although the server process itself is an
application-level process, it is fully protected from and invisible to the application that called it.
From the 2GB to the 4GB mark are
Windows NT’s low-level Ring 0 system
components including the kernel, thread
scheduling, and the virtual memory manager. System pages in this region are
marked with Supervisor privileges that
are physically enforced by the processor’s
ring protection scheme. This keeps lowlevel system code from being visible to or
writable by application-level code—and
exacts a performance penalty when ring
transitions occur.
Windows NT provides Windows on
Windows (WOW) sessions for running
16-bit Windows applications. As with
OS/2 Warp, Windows NT can run 16-bit
Windows programs individually in private
memory spaces or together in a shared address space. In almost all cases, 16-bit and
32-bit Windows applications can intercommunicate freely using OLE (via
thunks when needed), regardless of
whether they run in private or shared
memory. Native applications and WOW
sessions are preemptively multitasked on
a per-thread basis. Multiple 16-bit Windows applications in a single WOW session are cooperatively multitasked. Windows NT can also multitask multiple DOS
sessions. Because Windows NT is a fully
32-bit design, there are no theoretical limits to GDI and USER resources.