INDIETRO
Let's define the difference between preemptive and cooperative multitasking. Preemption is an involuntary loss of control which the application must handle. Cooperative multitasking is where the application is given control and it is the application's responsibility to give up control so that other applications may execute.
The move to a preemptive multitasking model represents a significant departure from Windows 3.1. Under that environment applications must "cooperate" in order for multitasking to occur. Each program "yields" to the operating system so that it can switch control of the PC's CPU to a different application (this is often referred to as "cooperative multitasking" or "task-switching").
It is a well know fact that the Windows "cooperative multitasking" model is inefficient. It also forces programmers to code their applications in a way that adds complexity and hinders performance. So it comes as no surprise that Microsoft's promise of preemptive multitasking in Windows 95 has been heralded as one of the new platform's most important features.
But the truth is that Microsoft isn't telling the whole story when it comes to Windows 95's multitasking architecture. In reality, unless you work exclusively with 32-bit "Win32" applications, you won't reap the benefits of true preemptive multitasking.
Why? Because of Windows 95's heavy reliance on 16-bit, Windows 3.1-era code. Under Windows 95, both 16-bit and 32-bit applications rely on 16-bit code structures that reside within the System VM - code that has been brought over from Windows 3.1.
While the "bitness" of the code itself isn't significant, the environment from which it hails is. Windows 3.1 was written as a cooperative, not preemptive, multitasking environment. When you introduce portions of its code into a preemptive setting, where more than one task may be vying for its services at any given time, the code could break.
To safeguard against this sort of "code breakdown," Microsoft has serialized access to key portions of the Windows 95 infrastructure - most notably the USER (window management) and GDI (graphics device interface) subsystems. In technical terms, this is referred to as a "non-reentrant" design, meaning that only one application may execute within these modules at any given time.
While such an approach works with Win32 applications - which can be preempted at any point during their execution - it breaks down once a 16-bit Windows (Win16) application begins to execute. As it stands, currently shipping Win16 applications cannot be reliably preempted during execution. Attempting to do so while such an application is calling on a non-reentrant, 16-bit code module can cause the entire operating system to crash.
To avoid this latter scenario, and thus retain some semblance of multitasking, Microsoft has implemented a special locking mechanism. Dubbed "Win1MUTEX," this mechanism denies access to the older code when a 16-bit application has called on its services. Thus only the currently running Win16 application has access to the 16-bit code - all other applications, including Win32 applications, are "blocked" from executing until the 16-bit application has finished and the environment has been made safe for the next task.
In practice, the performance hit associated with this locking phenomena is minimal when running 32-bit applications exclusively. However, when you introduce a mixture of 16 and 32-bit applications - the most likely scenario given the projected lack of available Win32 products - Win1MUTEX becomes a major problem.
Most 16-bit Windows applications are notorious for failing to yield properly under Windows 3.1, and until they do so under Windows 95, all other applications will be blocked from accessing USER and/or GDI (in reality, only 50% of GDI calls are affected - but these are the most common functions so the net result is the same).
Taken as a whole, these two compromises - the serialization of subsystem access and Win1MUTEX - create what would best be described as a "semi-preemptive" multitasking environment. And while the resulting "hourglass" is expected under a cooperatively multitasked environment, it seems out of place in a "next generation" Windows that supposedly "preemptively multitasks" native Win32 applications.
And thanks to its ability to run them in separate VDMs, OS/2 can also preemptively multitask existing 16-bit Windows applications which Windows 95 can not. Thus you can have DOS, Windows, and OS/2 applications running concurrently, side-by-side, without any performance penalties and all preemptively multitasked. This is a feature that Windows 95 seems to be unable to match without underlying architecture changes, and a welcome addition to any power-user's arsenal.
1994 IBM Corporation. All Rights Reserved.
OS/2 is a registered trademark of International Business Machines Corporation.
Microsoft is a registered trademark and Windows is a trademark of Microsoft, Inc.
NetWare is a registered trademark of Novell, Inc.
INDIETRO
back to ppj links