
**************************************************
* 15 questions to ask Microsoft about Windows 95 *
**************************************************


These answers are based upon published information from the "Windows
95 Resource Kit" and "Windows 95 Reviewer's Guide".



About Reliability
=================

Q: What happens to 32-bit applications when a Win16 application
crashes under Windows 95?

A: They can stop executing. Because Microsoft built Windows 95 using
the same System Virtual Machine (VM) model found in Windows 3.1, the
operating system is at the mercy of legacy 16-bit applications. If a
Win16 program hangs, it can tie up critical 16-bit code modules
located in the System VM. All other processing is halted.

BOTTOM LINE: WINDOWS 95 IS NOT A RELIABLE PLATFORM FOR MISSION
CRITICAL LINE-OF-BUSINESS APPLICATIONS.

Q: Does Windows 95 protect the contents of its system cache against
intrusion by Win32 programs?

A: No. As with the aforementioned system structures, Windows 95 also
fails to protect the contents of its system cache - disk cache,
network cache, and CD-ROM cache. As a result, an errant Win32
application can write to memory in use by the cache . The potential
results: inaccurate data, corrupted file system entries, etc.

BOTTOM LINE: DATA INTEGRITY IS A QUESTIONS MARK WITH WINDOWS 95.

Q: How is Microsoft dealing with the issue of Virtual Device Driver
(VxD) instability?

A: They aren't. In fact, Windows 95 itself makes heavy use of VxDs to
supplement and, in many cases, replace DOS functionality. VxDs are
extremely powerful programs that can literally go anywhere and do
anything in the operating system.  They have free reign to address
system memory directly, manipulate hardware, and even replace portions
of Windows 95 itself at runtime. This give the creative VxD programmer
unlimited flexibility when designing applications that need to modify
Windows 95's operation. Microsoft has itself often promoted the VxD
interface as a mechanism for gaining good performance with
time-critical Windows applications.  Unfortunately, the power of the
VxD can also be a curse. As more developers begin to exploit this
interface - an interface that has only limited controls and almost
zero inter-process isolation - a programming free-for-all may result
where multiple third party VxDs modify the system in similar ways with
unpredictable results. The failure of a single VxD can undermine the
stability of the entire Windows 95 environment.

BOTTOM LINE: VxDs ARE POTENTIAL DISASTERS WAITING TO HAPPEN IN
CORPORATIONS WORLDWIDE.

Q: Is it true that Windows 95 doesn't fully protect its own operating
system code against Win32 application failures?

A: Yes. Win32 applications can write to regions of the extreme lower
and upper address spaces in the System VM that are critical to the
environment's operation. As a result, an errant memory operation can
undermine system stability and potentially crash the entire operating
system.

BOTTOM LINE: WINDOWS 95 MAY BE ONE ERRANT MEMORY OPERATION AWAY FROM
TOTAL FAILURE.

Q: When running DOS applications, does Windows 95 fully virtualize the
PC's hardware to protect against buggy applications?

A: No. Windows 95 fails to virtualize critical hardware components
like the interrupt flag. This, in turn, can lead to a system crash if
an errant DOS program becomes unresponsive while interrupts are
disabled.

BOTTOM LINE: LEGACY APPS ARE THE ACHILLES HEEL OF WINDOWS 95 MEMORY
MANAGEMENT.



About Usability
===============

Q: Does Windows 95 track objects dynamically?

A: No. Windows 95 uses a series of static DOS pathnames and .INI files
to track the relationship between icons on the desktop and files on
disk. For example, the shortcut mechanism of the Windows 95 interface
relies on a stored copy of the original's path information when
locating and invoking it. If the file is moved within the directory
structure, Windows 95 must search the hard disk for it based on file
size and date stamp. Although this technique works most of the time,
it is limited to searching a single volume - if you move the file to
another disk volume, the link is broken completely. And, because
Windows 95 will search your entire network if attached, it may take
forever if it is connected to, say, five gigabytes of storage.

BOTTOM LINE: HELP DESK CALLS WILL BE ON THE RISE AS USERS EXPERIMENT
WITH SHORTCUTS AND LONG FILENAMES.

Q: Does Windows 95 make consistent use of drag & drop? 

A: No. Windows 95's drag & drop features are applicable to some
objects, like files and folders, but not to others. You cannot, for
example, drag a dial-up networking connection to the Windows 95
Recycler; nor can you drag objects to the My Computer folder - both
are "special" objects in the Windows 95 interface and aren't subject
to the normal Windows 95 drag & drop rules. This introduces a level of
inconsistency to the interface and a possible stumbling block for new
users trying to take advantage of drag & drop.

BOTTOM LINE: THE WINDOWS 95 INTERFACE IS INCONSISTENT FROM "FUNCTION
TO FUNCTION."

Q: Is the Windows 95 interface consistent and object-oriented? 

A: No. For example, while you can invoke the right mouse button pop-up
menu on most objects, entries in the Start menu and its submenus are
not included. This makes manipulating Start menu entries an awkward
process involving the Taskbar properties dialog box and several
layers of menus and windows. Since the right mouse button works in
most other areas of the interface, the Start button's deviation from
this norm exposes Windows 95's object-oriented support as incomplete.

BOTTOM LINE: WINDOWS 95 DOES NOT FULLY EXPLOIT O-O TECHNOLOGY.



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.

