About Windows 95 and Multitasking

Q: Can Windows 95 preemptively multitask Win16 applications?

A: No.  Because Win16 applications were written for a cooperative multitasking environment, they cannot handle the stress of being  "preempted" during execution.  Therefore Windows 95 must handle these applications in the same way that Windows 3.1 does: by giving them exclusive control of the CPU for as long as they are executing.  When, and only when, the application makes a specific API call - one of the few such calls that constitute safe points at which Windows can wrest control away from the program - are other programs allowed to execute.  This is "cooperative" multitasking, and has proven to be ineffectual when running more than a handful of programs simultaneously or when running CPU-intensive programs such as communications, print and/or fax programs. BOTTOM LINE:  WINDOWS 95 ADDS LITTLE VALUE FOR THE LARGE BASE OF LEGACY WIN16 APPLICATIONS.

Q: Are there any caveats to multitasking Win32 applications under Windows 95?

A. Yes.  In its effort to maintain a high degree of backward compatibility while simultaneously minimizing the RAM requirements of the operating system, Microsoft has chosen to rely on its existing, Windows 3.1-era USER (window management) and Graphics Device Interface (GDI) modules rather than create new, 32-bit versions. In order to utilize this older, 16-bit code in potentially preemptive (with regard to Win32 applications), 32-bit multitasking environment of Windows 95, Microsoft was forced to serialize access to USER and GDI.  As a result, only a single Win32 or Win16 program can access these critical modules at any given time. This hurts application performance on heavily loaded systems as programs are forced to "line-up" and wait for a chance to execute a USER or GDI routine. All USER calls (for both 16 and 32-bit applications) are serialized and handled by the 16-bit code, while the majority of GDI calls are similarly handled (the other 50 percent are handled by newer 32-bit routines). BOTTOM LINE:  WINDOWS 95'S MULTITASKING IS BEST DESCRIBED AS PREEMPTIVELY CHALLENGED.

Q: What happens to Windows 95's multitasking when you run a mixture of application types?

A: It reverts to a cooperative multitasking model.  Windows 95's continued reliance on the single system VM model of Windows 3.1 places the operating system's multitasking capabilities at the mercy of the lowest common denominator: the 16 bit Windows application.  Whenever a Win16 application is running, the operating system's multitasking capabilities are compromised by the need to allow such programs to execute "undisturbed" for as long as they require.  As a result, when multitasking a mixture of applications - Win16 and Win32 - true preemptive operation is impossible since, at any given time, a 16-bit  application may require exclusive control of the CPU. Worse still, since the Win16 application is typically executing a portion of the 16-bit USER or GDI code - access to which must be serialized among processes -all other processes, including Win32 applications, are blocked from executing.  The net result is what would be best described as "semi-preemptive" multitasking. BOTTOM LINE:  WHEN WIN16 APPLICATIONS ENTER THE MIX, WINDOWS 95 TAKES ON AN ALTERNATE PERSONALITY WINDOWS 3.1

Q: Does Windows 95's multitasking resolve any of Windows 3.1's multimedia-related deficiencies?

A: Not really.  Windows 95's inconsistent multitasking performance - a byproduct of the single System VM model - compromises its performance as a serious multimedia production platform. Complex .AVI clips break up noticeably when a significant I/O strain is placed on a Windows 95 system.  Even simple operations, like opening an application program, can have a negative impact on multimedia playback. BOTTOM LINE:  YOU STILL CAN'T PLAY MULTIMEDIA AND DO HEAVY I/O SIMULTANEOUSLY.

About Windows 95's relationship to DOS

Q: Does Windows 95 really do away with DOS?

A: No.  Windows 95, though touted as a completely new, 32-bit operating system, is in fact still based on DOS technology that dates back to the early 1980s.  Under Windows 95, even Win32 applications rely on at least a few data structures within the real mode DOS environment (most notably, they all maintain real mode PSPs).  Despite Microsoft's claims to the contrary, Windows 95 is highly sensitive to the configuration of a PC's real mode DOS environment.  If, for example, the available conventional memory in the System VM - the DOS virtual machine where all 16-bit Windows applications and some Windows 95 codes executes - dips below a certain level, Windows 95 will report "out of memory" messages when you try to open additional Win16 or Win32 programs.  This is unrelated to the well known System Resources phenomena, and the only real solutions are to either replace as many real mode device drivers as possible with VxDs or to invest in a third party memory manager to optimize the pre-Windows 95 DOS environment. BOTTOM LINE:  WINDOWS 95 CAN BE VIEWED AS DOS/WINDOWS with a new INTERFACE AND SOME NEW VxDs.

Q: What is Single MS-DOS Application mode and how does it affect other running applications?

A: Microsoft touts Single MS-DOS Application (SMA) mode as its ultimate solution to any and all DOS compatibility complaints. SMA is essentially real mode DOS, except that instead of booting DOS and then loading Windows, the order has been reversed: you first boot Windows 95, then "unload" it as the machine is reset into the real mode of SMA. This indeed eliminates virtually all remaining DOS application incompatibilities since the PC is no longer running in V86 protected mode - it has been reset to real mode, loaded with a copy of DOS, and left at a command prompt. What Microsoft doesn't like to admit, however, is that to invoke an SMA-dependent application is to essentially shut-down Windows 95 - all running applications are closed, network connections are severed, and VxD support for peripherals like CD-ROM drives disappears. To maintain these functions you need to add real mode DOS device drivers to your system and then configure them via the SMA dialog box.  And since Windows 95 is no longer running, any users who are connected to shared resources on the system are disconnected when it enters into SMA mode. BOTTOM LINE:  SMA IS REALLY ONLY A VIABLE SOLUTION FOR HOME USERS AND OTHER NON-NETWORKED ENVIRONMENTS

Q: How does Windows 95 handle real mode DOS device drivers?

A: Windows 95's dependency on the real mode DOS environment undermines the product's ability to support DOS applications. Because Windows 95 relies on an "image" of the pre-Windows 95 boot-up environment when creating the System VM, and because subsequent DOS virtual machines are similarly based on this boot-up image, Windows 95 users are forced to load any required real mode device drivers as part of the original boot-up CONFIG.SYS file.  The ramifications of this limitation are significant:  each and every DOS session under Windows 95 contains a running copy of, and surrenders valuable conventional or upper memory to, real mode device drivers.  This is true even if the drivers are not required or desired in a particular DOS session. BOTTOM LINE:  THERE'S NO WAY TO LOAD A REAL MODE DRIVER INTO A SPECIFIC DOS SESSION -- IT'S AN ALL OR NOTHING PROPOSITION.

Bookmark/Search this post with:
delicious | digg | reddit | furl | technorati | icerocket