<+!><:f,BLotusLineDraw,>Bottom Line: Windows 95 can be viewed as DOS/Windows with a new interface and some new VxDs.<:f><-!>
>
52 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: What is Single MS-DOS Application mode and how does it affect other running applications?<:f>
>
52 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 b
een 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 b
een 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, net
work 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 runnin<:f,BLotusLineDraw,>g, any users who are connected to shared resources on the system are disconnected when it enters into SMA mode.<:f>
>
54 1 0 0 0 0 0 1 0 0 0 0
<:f,BLotusLineDraw,><+!>Bottom Line: SMA is really only a viable solution for home users and other non-networked environments.<-!>
>
55 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: How does Windows 95 handle real mode DOS device drivers?<:f>
>
55 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 signific
ant: 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.<:f>
>
56 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<-!>
>
57 1 0 0 0 0 0 1 0 0 0 0
<:f,BLotusLineDraw,><+!>Bottom Line: There's no way to load a real mode driver into a specific DOS session -- it's an all or nothing proposition.<-!>
@Body Text@<:f,BLotusLineDraw,>Q: What happens to 32-bit applications when a Win16 application crashes under Windows 95?<:f>
@Body Text@
>
2 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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.<:f>
>
4 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: Windows 95 is not a reliable platform for mission critical, line-of-business applications.<-!><:f>
>
6 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: Does Windows 95 protect the contents of its system cache against intrusion by Win32 programs?<:f>
>
6 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 b
y the cache. The potential results: inaccurate data, corrupted file system entries, etc.<:f>
>
8 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: Data integrity is a question mark with Windows 95.<-!><:f>
>
9 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: How is Microsoft dealing with the issue of Virtual Device Driver (VxD) instability?<:f>
>
9 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<-!><-!><:f,BLotusLineDraw,>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 operatin
g system. They have free reign to address system memory directly, manipulate hardware, and even replace portions of Windows 95 itself at runtime. This gives 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 sing
le VxD can undermine the stability of the entire Windows 95 environment.<:f>
>
11 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: VxDs are potential disasters waiting to happen in corporate America.<-!><:f>
>
13 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: Is it true that Windows 95 doesn't fully protect its own operating system code against Win32 application failures?<:f>
>
13 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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.<:f>
>
15 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: Windows 95 may be one errant me<:f,BLotusLineDraw,>mory operation away from total failure.<-!><:f>
>
17 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: When running DOS applications, does Windows 95 fully virtualize the PC's hardware to protect against buggy applications?<:f>
>
17 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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.<:f>
>
18 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: Legacy apps are the Achilles heel of Windows 95 memory management.<-!><:f>
>
19 0 0 0 0 0 0 1 0 0 0 0
@Subhead@<:f,BLotusLineDraw,>About Usability<:f>
>
21 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: Does Windows 95 track objects dynamically?<:f>
>
21 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 limit
ed 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<:f>
<:f,BLotusLineDraw,>.<:f>
>
23 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: Help desk calls will be on the rise as users experiment with shortcuts and long filenames.<-!><:f>
>
25 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: Does Windows 95 make consistent use of drag & drop?<:f>
>
25 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 t
he 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 t
ake advantage of drag & drop.<:f>
>
27 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: The Windows 95 interface is inconsistent from function to function.<-!><:f>
>
28 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: Is the Windows 95 interface consistent and object-oriented<:f><:f,BLotusLineDraw,>?<:f>
>
28 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 Taskb
ar 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.<:f>
>
30 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: Windows 95 does not fully exploit<-!><:f><+!><:f,BLotusLineDraw,> O-O technology.<-!><:f>
>
32 0 0 0 0 0 0 1 0 0 0 0
@Subhead@<:f,BLotusLineDraw,>About Windows 95 and Multitasking<:f>
>
34 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: Can Windows 95 preemptively multitask Win16 applications?<:f>
>
34 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 Wi
ndows 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 f
rom 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 a
nd/or fax programs.<:f>
>
36 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: Windows 95 adds little value for the large base of legacy Win16 applications<-!>.<:f>
>
37 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: Are there any caveats to multitasking Win32 applications under Windows 95?<:f>
>
37 1 2048 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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, Widows 3.1-era USER (window management
) and GDI (Graphics Device Interface) 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 f
orced 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
).<:f>
>
39 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: Windows 95's multitasking is best described as "preemptively challenged."<-!><:f>
>
40 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: What happens to Windows 95's multitasking when you run a mixture of application types?<:f>
>
40 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 1
6-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.<:f>
>
42 1 2048 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,><+!>Bottom Line: When Win16 applications enter the mix, Windows 95 takes on an alternate personality: Windows 3.1.<-!><:f>
>
44 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: Does Windows 95's multitasking resolve any of Windows 3.1's multimedia-related deficiencies?<:f>
>
44 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 signi
ficant 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.<:f>
>
46 1 0 0 0 0 0 1 0 0 0 0
<:f,BLotusLineDraw,><+!>Bottom Line: You still can't play multimedia and do heavy I/O simultaneously.<-!>
>
47 0 0 0 0 0 0 1 0 0 0 0
@Subhead@<:f,BLotusLineDraw,>About Windows 95's relationship to DOS<:f>
>
49 0 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>Q: Does Windows 95 really do away with DOS?<:f>
>
49 1 0 0 0 0 0 1 0 0 0 0
@Body Text@<:f,BLotusLineDraw,>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 structu
res 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 Wi
n32 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
@Title@<+@><:#2880,9360><:f400,BLotusLineDraw,>Can Windows 95 live up to the hype that Microsoft has generated for it? These questions, which are based upon published information about the final beta product in the "Windows 95 Resource Kit" and "Windows 95 Reviewer's Guide," might
