A USER VIEW ON BENEFITS AND COSTS OF UPGRADING TO IBM OS/2 WARP CONNECT, MICROSOFT WINDOWS 95 AND MICROSOFT WINDOWS NT 3.51 WORKSTATION AND A PRELIMINARY USER VIEW OF IBM OS/2 WARP CONNECT "MERLIN" AND WINDOWS NT 4.0 WORKSTATION August 1, 1996 Introduction ------------ Today, most corporate and small office/home office (SOHO) personal computer users are using Windows (or Windows for Workgroups) 3.1/3.11 to run office automation and decision support programs. These users are under continuous pressure to increase productivity (reduce costs and save time), increase quality and improve service. These same pressures also apply, but to a lesser degree, to consumer (i.e. home, other than home office) users of personal computers. Software developers are currently pushing 16-bit Windows programs to their limits. In order to meet increased productivity, quality and service requirements, personal computer users will need to migrate to more powerful operating systems and native application programs for these more powerful operating systems. Many of today's new mission critical client/server systems have already found 16-bit Microsoft Windows environments inadequate for their price/performance requirements. In order to achieve higher levels of price/performance, these mission critical client/server systems are being built with clients that are personal computers that use a 32-bit preemptive multithreaded multitasking operating system, which is often IBM OS/2, and 32-bit multithreaded native application programs for the operating system. The multithreaded clients are connected to servers. A server runs a 32-bit preemptive multitasking operating system, which is often OS/2 or UNIX, and 32-bit native application programs for the operating system. The servers often communicate to mainframes or other large systems. Analysis -------- For the purpose of this analysis, the benefits of upgrading to native 32-bit multithreaded programs for a 32-bit preemptive multithreaded multitasking operating system will be assumed to be comparable for all operating systems for which 32-bit multithreaded programs can be developed. This simplifies the benefits portion of the benefit/cost analysis. Since all 32-bit operating systems that are currently generally available or are under beta test have the comparable benefit of enabling developers to create 32-bit multithreaded programs, the key issue is how to minimize hardware upgrade costs, software upgrade costs and support costs while achieving these benefits. The following analysis compares three generally available 32-bit preemptive multithreaded multitasking operating systems: o IBM OS/2 Warp Connect o Microsoft Windows 95 o Microsoft Windows NT 3.51 Workstation and a preliminary comparison of operating systems, currently in beta test, that will be the next releases of two of the three above alternatives: o IBM "Merlin" (which is the codename for the next version of OS/2 Warp Connect) o Microsoft Windows NT 4.0 Workstation For the purposes of the analysis, the terms "Warp" and "Warp Connect" will be used interchangeably. IBM has said that Merlin and future versions of OS/2 will all include local area network (LAN) connectivity, which is the primary difference between Warp and Warp Connect. Furthermore, IBM has said that by the end of 1995 most new copies of OS/2 Warp were OS/2 Warp Connect. I propose that there are four key attributes of an operating system that will minimize upgrade costs. If the user wishes, these cost minimization attributes may be considered to be additional benefits associated with upgrading to a particular 32-bit preemptive multithreaded multitasking operating system. 1. Backwards Compatibility with DOS and Windows 3.1 programs. The operating system must provide the maximum possible backwards compatibility with today's 16-bit DOS and Windows 3.1 programs. Backwards compatibility is provided best by operating systems that include real, but modified, Windows or Windows for Workgroups 3.1/3.11 code and do not use emulation. Emulation can introduce problems with backwards compatibility. Backwards compatibility allows the user to avoid unnecessary software upgrades and the associated software costs and support costs. 1.a. IBM OS/2 Warp Connect: IBM OS/2 Warp uses real, albeit modified, Windows 3.1 code. IBM received the rights to the Windows 3.1 code in perpetuity as a result of the Joint Development Agreement (aka "divorce decree") between IBM and Microsoft. Information about incompatibilities for DOS and Windows 3.1 programs running under OS/2 Warp may be found by opening (double-clicking) the "Information" icon on the OS/2 Warp desktop (Workplace Shell) and then opening (double-clicking) the "Applications Consideration" icon. The Applications Consideration document is part of the "Documentation" that is installed when OS/2 Warp is installed (note: OS/2 Warp installation installs "Documentation" by default). The Applications Consideration document is not otherwise electronically available from IBM. 1.a.1. IBM Merlin: The only change that IBM has announced is that it is enhancing support for DPMI to "DPMI 1.0 Subset". Merlin should be at least as backwards compatible with DOS and 16-bit Windows programs as is OS/2 Warp Connect today. 1.b. MS Windows 95: Microsoft Windows 95 uses modified Windows for Workgroups 3.11 code (note: refer to section 4.b. of this analysis, Robust Multitasking - MS Windows 95, for a source for this statement). Because the Windows for Workgroups 3.11 code has been modified in Windows 95, some Windows 3.1 programs do not work correctly under Windows 95. Microsoft has published a "Windows 95 Software Compatibility Report" that lists compatibility or incompatibility of 2500 DOS and Windows programs with Windows 95. The file name of the report is WIN95APP.HLP. It can be downloaded from Compuserve and other sources. The report has been criticized from two points of view. First, the report sometimes lists a particular Windows program as having one or more problems with Windows 95 and may not list that a later version is compatible with Windows 95. This is not surprising because software is often updated. Microsoft has announced plans to update the report weekly. As of August 1, 1996, more than 11 months after the general availability of Windows 95, the July 1995 Draft of the report was still the version available from the Compuserve WINNEWS forum. Second, the report sometimes say "no problems noted" when users have found that there are problems. An often reported example of this is that installing the Microsoft Internet Explorer (a World Wide Web browser program) or the Microsoft Network access software causes a particular file (WINSOCK.DLL) for a third party Internet World Wide Web (WWW) browser program (e.g. Netscape Navigator or Compuserve NetLauncher) to be renamed and the Microsoft Windows 95 version of the file (WINSOCK.DLL) to be installed. When the new version of the file (WINSOCK.DLL) is used with the third party WWW program, the third party program does not work. This normal behavior of Microsoft's programs for Windows 95 is not included in the "Windows 95 Software Compatibility Report". 1.c. MS Windows NT 3.51 Workstation: Microsoft Windows NT 3.51 rates lower on the backwards compatibility attribute. It emulates Windows 3.1 instead of using a modified version of Windows 3.1/3.11 or Windows for Workgroups 3.1/3.11. The Windows on Windows (WOW) subsystem (or layer) in all versions of Windows NT is the emulator. Microsoft sometimes refers to its emulation approach as translation. The article, "Win95 vs NT Workstation", Datamation, November 15, 1995, pp 69-71 compares these two operating systems on several attributes. On page 70 the article discusses backwards compatibility of Windows NT 3.51 Workstation with 16-bit Windows programs: ' Microsoft admits that NT Workstation (note: version 3.51) poses more compatibility problems than Windows95. NT runs Win16 applications in emulation mode. Jeff Thiel, group product manager at Microsoft, says incompatibilities will exist mostly with applications that directly access the hardware -- such as certain utilities and relatively sophisticated home-grown code -- and with applications that rely on Windows/DOS device drivers. Thiel admits that application incompatibilities could represent the most costly aspect of upgrading to NT Workstation -- more costly than the expenses associated with upgrading processors, memory and disks.' This compatibility analysis has been updated recently in "NT Workstation: Is It Your Next Corporate Desktop?", Datamation, May 15, 1996, pp 89-94. The compatibility analysis is on page 91: ' And, despite Microsoft's original promises, the 'Designed for Windows 95' logo does not guarnatee compatibility with NT Workstation.' ' "It's a widely held misperception that all applications with the Win95 logo will run on NT. It's just not true," says Window Watcher's (editor Dwight) Davis. Megan Bliss, Microsoft's group product manager for NT Workstation, claims that NT Workstation runs about 95 percent of the applications that carry the Win95 logo.' ' In general, about 80 percent of all 16-bit applications (including off-the-shelf and custom apps) will run on NT Workstation, according to several analysts and users.' According to the article "You Mean NT CAN'T Really Run WINDOWS", (Datamation, May 15, 1994, pp 67-68), the Microsoft Windows NT Windows on Windows subsystem uses Insignia Solutions Softwindows technology that emulates Windows 3.1. More detailed information is in Attachment A, "Windows NT Backwards Compatibility with Windows 3.1 Programs: Emulation and the Use of Insignia Solutions' Softwindows Technology". At the time that Windows NT 3.1 was developed, SoftWindows 1.0 was available. It supported standard mode Windows programs but not enhanced mode Windows programs. As the above article discusses, Microsoft modified the Windows on Windows subsystem programming for NT 3.5. The subsystem was further modified for Windows NT 3.51 Workstation. Finally, Windows NT 3.51 rates lower than the earlier Windows NT 3.5 on the backwards compatibility attribute. The following is an electronic mail message to me that explains part (or all) of this loss of backwards compatibility: > #: 385 S0/CompuServe Mail > Sb: NT 3.51 & Win Apps > > My gripe was the drop in backward compatability between NT 3.5 and > 3.51. I was able to confirm my suspicions with one of the serious > programmers at work. Per him, there were a number of GDI 'handles" > in 3.5 designed to support the WIN16 emulation that were "renamed" > to new Win-95 style 32-bit API functions for the NT 3.51 GDI. > Thus any of the Win16 stuff that calls these GDI functions will > either cause GPFs (passing parameter errors) or erronous color > functions. I consider this approach used by Microsoft to be an > inappropriate programming shortcut that is not very professional. 1.c.1 MS Windows NT 4.0 Workstation: Microsoft Windows NT 4.0 may rate better than, comparable to or worse than Windows NT 3.51 on the backwards compatibility attribute when it becomes generally available. Microsoft is changing the emulation in Windows NT 4.0 to support enhanced mode Windows programs in addition to the standard mode Windows programs supported by the emulation in Windows NT 3.51. Depending on how the change in the emulation programming is accomplished, it might result in backwards compatibility in Windows NT 4.0 that is better than, comparable to or worse than the backwards compatibility in NT 3.51. 2. Minimal or No Memory (RAM) Increase. The operating system must run with acceptable speed on today's personal computer configurations. These configurations typically have 8 MB or 16 MB of memory (RAM). In other words, there should be minimal or no RAM increase (upgrade) required to install and begin to use the new 32-bit operating system. A personal computer using the operating system attached to a local area network (LAN) using the appropriate LAN requester must run with acceptable speed with a DOS or small Windows program in 8 MB RAM. The user minimizes memory hardware upgrade costs. Since LAN requesters for these operating systems typically require 2 MB to 4 MB RAM, one can do the arithmetic if one is looking at memory requirements when the personal computer is not attached to a LAN. 2.a. IBM OS/2 Warp Connect: IBM OS/2 Warp Connect on a personal computer attached to a local area network using the appropriate LAN requester can do this. IBM specifies OS/2 Warp Connect's minimum memory requirements to be 8 MB RAM. 2.a.1. IBM Merlin: IBM is claiming that the memory requirements for Merlin will be the same as the memory requirements for OS/2 Warp Connect. It remains to be seen whether this is true when Merlin becomes generally available. 2.b. MS Windows 95: Microsoft Windows 95 on a personal computer attached to a local area network using the appropriate LAN requester can do this. 2.c. MS Windows NT 3.51 Workstation: Microsoft Windows NT 3.51 running on a personal computer attached to a local area network using the appropriate LAN requester has been widely reported to require 16 MB RAM minimum with even a small 16-bit Windows program and therefore does not possess the minimal hardware upgrade attribute. 2.c.1. MS Windows NT 4.0 Workstation: Microsoft Windows NT 4.0 has some significant design differences from Microsoft Windows NT 3.51 (note: refer to section 4.c.1 of this analysis, Robust Multitasking - Microsoft Windows NT 4.0, for information about these changes). Microsoft is claiming that the memory requirements for Microsoft Windows NT 4.0 Workstation will be the same as the memory requirements for Microsoft Windows NT 3.51 Workstation. It remains to be seen whether this is true when Microsoft Windows NT 4.0 Workstation becomes generally available. 2.d. Operating Systems Memory Requirements Comparison: The above memory requirements are only minimums. The following table reflects information published in many benchmark tests in magazines and also user messages posted on Compuserve. The definitions of "Workable" memory and "Sweet Spot" memory are necessarily subjective. However, system performance is significantly improved for all users by upgrading from "Minimum" to "Workable" memory. Performance is further improved by upgrading from "Workable" memory to "Sweet Spot" memory. A small proportion of users benefit from upgrading beyond "Sweet Spot" memory. Operating Systems Memory Requirements Comparison Local Area Local Area Local Area Network Network Network Connection Connection Connection Minimum Workable Sweet Spot Memory Memory Memory IBM OS/2 Warp Connect 8 MB RAM 12 MB RAM 16 MB RAM IBM Merlin unknown unknown unknown MS Windows 95 8 MB RAM 12 MB RAM 16 MB RAM MS Windows NT 3.51 Workstation 16 MB RAM 24 MB RAM 32 MB RAM MS Windows NT 4.0 unknown unknown unknown Workstation 3. No Microprocessor Upgrade. The operating system must run today's 16-bit DOS and Windows programs "fast". In other words, users should not have to upgrade their personal computer systems with more powerful microprocessors or buy new more powerful systems just to run 16-bit DOS and Windows programs that they cannot or will not soon upgrade. The user minimizes microprocessor hardware upgrade costs. Today, IBM specifies that OS/2 Warp will run and be supported on personal computers with Intel 386SX or more powerful microprocessor. Similarly, Microsoft specifies that Windows 95 and Windows NT 3.51 will run and be supported on personal computers with Intel 386DX or more powerful microprocessor. However, IBM and Microsoft have said that Merlin and Windows NT 4.0 respectively will be supported only on personal computers that have a minimum Intel 486SX microprocessor or equivalent. They apparently are both eliminating compatibility testing on Intel 386SX and 386DX microprocessor based personal computers. 3.a. IBM OS/2 Warp Connect: IBM OS/2 Warp can do this. IBM OS/2 Warp runs Windows 3.1 programs almost as fast as Windows 3.1, which is the basis of its Windows program support (as mentioned in section 1.a. of this analysis, Backwards Compatibility with DOS and Windows 3.1 programs - OS/2 Warp). 3.a.1. IBM Merlin: IBM is claiming that the processor requirements for Merlin will be the same as the processor requirements for OS/2 Warp Connect. It remains to be seen whether this is true when Merlin becomes generally available. 3.b. MS Windows 95: Microsoft Windows 95 can do this. Microsoft Windows 95 runs Windows 3.1 programs almost as fast as Windows for Workgroups 3.11, on which it is based (refer to section 4.b. of this analysis, Robust Multitasking - Windows 95, for a source for this statement. 3.c. MS Windows NT 3.51 Workstation: On the other hand, Microsoft Windows NT 3.51 is widely reported to run many 16-bit Windows programs slower than either of the other two operating systems and does not possess this performance attribute. 3.c.1. MS Windows NT 4.0 Workstation: Microsoft Windows NT 4.0 has some significant design differences from Microsoft Windows NT 3.51 (note: refer to section 4.c.1 of this analysis, Robust Multitasking - Microsoft Windows NT 4.0, for information about these changes). Microsoft is claiming that the processor requirements for Microsoft Windows NT 4.0 Workstation will be the same as the processor requirements for Microsoft Windows NT 3.51 Workstation. It remains to be seen whether this is true when Microsoft Windows NT 4.0 Workstation becomes generally available. 4. Robust Multitasking. The operating system must provide robust multitasking so that no program -- whether 16-bit DOS, 16-bit Windows or 32-bit native to the operating system -- can cause any other program to stop running. Robust multitasking has two basic requirements: i. The operating system must have a robust multitasking design that prevents any program from causing any other program to stop running. ii. The operating system should not have any bugs that compromise its robust multitasking design or cause the operating system to crash, stopping all programs that are running. These bugs must be eliminated for an operating system to be used successfully Robust multitasking helps the user minimize support costs. 4.a. IBM OS/2 Warp Connect: IBM OS/2 Warp is a robust multitasking operating system. It has a robust multitasking design and has few bugs. IBM has trademarked the robust multitasking design attribute for OS/2 and called it "OS/2 Crash Protection". OS/2 Crash Protection is based on the fact that each OS/2 program runs in its own separate session, each DOS program runs in its own separate session and -- if the users chooses or needs to do so -- each 16-bit Windows program runs in its own separate session. If a single session locks up and stops, OS/2 itself and all other sessions (DOS, Windows or OS/2) continue to run. Because OS/2 continues to run, the user can easily terminate the stopped session and restart it. IBM OS/2 Warp seems to have fewer bugs than its predecessor, OS/2 2.1. This conclusion is based on messages posted by OS/2 users on the Compuserve OS2USER forum. 4.a.1. IBM Merlin: IBM is making improvements to the architecture of the "system input queue" which should improve the smoothness and robustness of Merlin's multitasking compared to OS/2 Warp Connect. IBM has already twice improved the architecture of the system input queue: first, OS/2 Warp was improved over OS/2 2.1 and more recently the February 1996 FixPak further improved the system input queue architecture. At a Spring 1996 Comdex presentation, Paul Giangarra, chief architect of Merlin, said that IBM has used the experience from the February 1996 Fixpak design to make further improvements. IBM is making another change to Merlin that is unlikely to have any noticeable impact on its robust multitasking. This change is to integrate OS/2 Security Enabling Services (SES) into Merlin. SES includes some kernel changes to OS/2 for the SES Kernel Programming Interface (KPI). There is also an SES Application Programming Interface (API). The reason that SES is unlikely to have any noticeable impact on Merlin's robust multitasking is that it has already been extensively beta tested. SES is of particular interest to the banking industry and third party software developers. Some of these firms participated in a closed SES beta test during 1995. Furthermore, SES was also part of the February 1996 FixPak and so has had further field testing. A recent product review (InfoWorld, July 8) and a more recent article about user reaction to the Merlin beta (InfoWorld) make no mention of bugs affecting its robust multitasking: o "Merlin desktop listens, obeys", InfoWorld, July 8, 1996, p. 103. o "Users evaluate Merlin's high and low points", InfoWorld, July 22, 1996, p. 31. The article "IBM speeds up timetable for 'Merlin' Warp update", PC Week, July 29, 1996, pp 1,108 says on page 1: '...IBM will issue a gamma test version to several hundred sites on August 9, then release the final code to manufacturing around August 29, sources close to the Armonk, N.Y., company said.' ' By then, IBM hopes to have cleared up the biggest complaint about the beta: problems with installation routines.' The article continues on page 108 with a range of user reactions: ' "It's a nightmare," said one reseller who requested anonymity. "Once you get it running, it's pretty stable, but getting it running is a major problem." ' "It's very stable -- as stable as anything we've seen released," said beta tester Jess Hurwitz, vice president of technology for Parallel Storage Solutions, a hardware manufacturer in Elmsford, N.Y., that uses OS/2 in-house.' ' Hurwitz said he had no installation problems but said his company has been careful to choose only hardware that follows design guides for 32-bit operating systems.' As this analysis is written, the Merlin beta test software seems to be as robust as the current, generally available Warp and Warp Connect products. 4.b. MS Windows 95: Microsoft Windows 95 is not a robust multitasking operating system. It does not have a robust multitasking design and it has many bugs. A dramatic example of the results of its design was related in "Of COM Ports and Digital Frogs", (Byte, September 1995, pp. 275-284) on pages 281-282: '...With only a few windows open, there's little difference in speed between OS/2 Warp Connect and the test versions of W95; but if you keep a lot of windows open and do a lot of multitasking, the differences can be dramatic.' ' Using the IBM Pentium ValuePoint (note: 60 MHz or 66 MHz Pentium), I've managed to get three simultaneous communications programs -- two using 9600 bps modems, and one using a serial port -- as well as a print job to run in OS/2. The printing was pretty slow, but the communications tasks worked without losing data. I haven't tried that with W95, but I don't need to. Just keeping a number of windows open (and doing nothing) will noticeably slow down W95.' The lack of robust multitasking in Windows 95 is partly a result of its design. As the article "A Grab Bag of Gotchas and Goodies for Programming in Windows 95" (Microsoft Systems Journal, May 1995, pp 19-34) says on page 30: '...There are still some 16-bit underpinnings in Windows 95, mainly due to backwards compatibility. A common misconception about Windows 95 is that it is based on Windows NT source code. This is not true. Windows 95 is based on Windows for Workgroups 3.11 code. Yes, the code has been significantly modified to provide process and thread memory management, IPC and synchronization, preemptive multitasking, I/O and printer services, and high level graphics operations, but there still are some occasional 16-bit issues to deal with' The relative importance of the use of modified Windows for Workgroups 3.11 code that is the basis for Windows 95 was noted by Andy Grove, President and CEO of Intel Corporation in the article about the Pentium Pro microprocessor, whose codename was P6, "P6 positioning is set" (PC Week, September 18, 1995 pp 1,131) on page 1: '" P6 is optimized for 32-bit software," Grove said in an interview last week. "It does not do anything very spectacular for Windows 95. Nor does it need to. [Win95] has 32-bit [code], but it is not predominantly 32-bit software."' The above statements summarize the design of Windows 95. More detailed information is in Attachment B, "The Design of Windows 95 and its Relation to Robust Multitasking". Windows 95 is the first release of a new operating system. It is buggy. It has installation bugs, which have been experienced by many people. For some people, the installation bugs have destroyed previous data that was stored on their hard disk. One example was described in "Dear Mr. Gates, Your program is one giant pane", New York Post, August 28, 1995, p. ??: ' Your cool-looking installation program worked great and within an hour told me that Windows 95 had been successfully installed.' ' Then it restarted my computer -- and all hell broke loose. Nothing worked. I won't go into all the details here because it would put everyone asleep. It's enough to say I think I have permanently lost many files that are impossible to replace, including a big chunk of a book I was writing.' ' But your instructions said I could undo all the damage with a nifty little program you dreamed up called "Uninstall" that would put everything as it was before Windows 95.' ' That brings us back to "UNDO.DAT." Windows told me I needed that file in order for the uninstall program to work.' ' But there's this problem -- I never got "UNDO.DAT." You never gave it to me.' ' I spoke to some people who successfully installed Windows 95 and they said they didn't get it either' ' Where is it?' After a successful installation, Windows 95 also crashes and has operational bugs. According to "Wanted: A PC for the Masses", Business Week, p.18: '...Windows 95, while an improvement over its predecessor (note: Windows/Windows for Workgroups 3.1x), still crashes distressingly often.' Several of the operational bugs were described in "Windows 95 Bugs Bear Out Advice", PC Week, December 20, 1995, p.77. The bugs included file and print services for Netware, accidental and irrecoverable data deletions, two security holes and a problem with long file names. 4.c. MS Windows NT 3.51 Workstation: On the other hand, Microsoft Windows NT 3.51 is a robust multitasking operating system. It has a robust multitasking design and few bugs. The robust multitasking of Windows NT was qualitatively and quantitatively compared to the robust multitasking of OS/2 Warp in the "Down to the Wire" column, InfoWorld, July 10, 1995, p. 88: ' The same Excel test (note: Excel 5.0 for Windows NT macro) slows down 72 percent in Windows NT [3.51] when running cc:Mail Remote [for DOS] in the background (note: compared to running Excel 5.0 for Windows NT macro with no other program running). You can get almost flawless performance in Windows NT if you tweak the multitasking settings. Unfortunately, the cc:Mail transfer works consistently only if you set NT to multitask with equal priority given to both foreground and background tasks. At any other setting, cc:Mail Remote often times out and disconnects before transferring all the pending mail.' ' I find it truly surprising how poorly Microsoft Windows NT handles this multitasking test. With all the fuss that even I have made about Windows NT's asynchronous input queues and robust architecture, I expected it to at least keep up with OS/2, if not run circles around it. But a similar spreadsheet test using Athena Design's Mesa 2 for OS/2 instead of Excel shows less than a 5 percent drop in the foreground application's performance; this is in OS/2 Warp when transferring the same cc:Mail Remote files in the background. And it's not just Mesa. Warp does consistently well with other 32-bit apps in the foreground.' In contrast to the situation with OS/2 Warp (which seems to have fewer bugs than its predecessor, OS/2 2.1), Windows NT 3.51 seems to have more bugs than its predecessor, Windows NT 3.5. The "Rumors" column of Windows NT Magazine, December 1995, p. 96 commented about the bugs in Windows NT 3.51: ' Version 3.51 was supposed to be a bug fix, but it didn't turn out that way for everyone. Lately, the nets have been full of stories about weird problems that only started when companies installed the latest version after months of trouble-free operation under 3.5. Most of the problems users are reporting are with drivers, especially ATI video drivers and some of the drivers for Adaptec disk controllers. Some of them can bring NT to a complete halt -- something that wasn't supposed to be possible. Another user tells me that some weird driver interaction is making 3.51 run re-e-eally slo-o-wly, almost like someone poured some amaretto syrup into the computer and gummed it up.' 4.c.1. MS Windows NT 4.0 Workstation: Two major architectural changes that Microsoft is making in Windows NT 4.0 (compared to Windows NT 3.51) may cause the multitasking of Microsoft Windows NT 4.0 to be less robust than the multitasking of Microsoft Windows NT 3.51 The most obvious change is that the Microsoft Windows 95 user interface is replacing the older Windows 3.1 user interface used on Microsoft Windows NT 3.51. This change may or may not result in new bugs in Microsoft Windows NT 4.0. It will likely increase memory and microprocessor requirements. The other important change is less obvious but perhaps more important. This second change is expected to offset the increased memory and microprocessor requirements due to the use of the Microsoft Windows 95 user interface and other enhancements in Windows NT 4.0. The second change is the architectural change of moving several parts of the Microsoft Windows NT architecture from the microprocessor's "User Mode" to its "Kernel Mode". The parts of the architecture that are moved from user mode to kernel mode include the Graphical Display Interface (GDI), the application interface (USER) and device drivers. Microsoft Windows NT has three major underlying subsystems: the operating system kernel, GDI and USER. In Windows NT 3.51, the operating system kernel (called the NT Executive) runs in the microprocessor's kernel mode and USER and GDI run in the microprocessor's user mode. According to information from the "Microsoft Windows NT 4.0 Beta 2 Reviewers Guide", April 1996 USER and GDI in Microsoft Windows NT 4.0 have been moved to the microprocessor's kernel mode. When a program running in the microprocessor's user mode (e.g. an end user program or GDI or USER in Microsoft Windows NT 3.51) encounters a bug and stops, only that program stops and the system can usually be recovered without stopping (crashing) other programs. This is the basis of robust multitasking. On the other hand, when a program (including GDI, USER and device drivers -- see below -- in Microsoft Windows NT 4.0) running in the microprocessor's kernel mode encounters a bug and stops, all programs on that system stop (crash). Therefore, Microsoft Windows NT 4.0's design that moves GDI and USER into the microprocessor's kernel mode ("Ring 0" in the Intel architecture) requires that GDI and USER be completely bug free for robust multitasking. The article "Windows NT 4.0", Windows NT Magazine, April 1996, pp 24-30 notes on page 28: ' Microsoft claims that these changes do not affect system stability, but many users undoubtedly will adopt a wait-and-see attitude'. The article mentions only that GDI is moved to the microprocessor's kernel mode. Its information, which seems to be earlier than the Reviewer's Guide referenced above, still has USER in the microprocessor's user mode. Therefore this analysis uses the Reviewer's Guide as the reference for these architectural statements. Microsoft has also moved the device drivers fom the microprocessor's user mode to kernel mode. The article "Don't get too excited about WinNT 4.0", Network World, May 20, 1996, p 35 focusses on Windows NT Server but it is also equally applicable to Windows NT Workstation when it says: ' Many of the drivers that ran in the protected ring 3 in NT Server 3.51 have been pushed into Ring 0 in NT 4. This should improve performance, but it means third-party software will be running in the unprotected ring 0, which could increase the possibility of server crashes.' The drivers that have been moved into kernel mode include drivers for: network interface cards (NICs), video cards, audio cards, etc. Other articles are beginning to appear that raise issues of NT 4.0's stability because of moving code from user mode to kernel mode: o "4.0 Isn't for Everyone: Has Microsoft traded stability for performance in the lastest NT release?", Byte Magazine, July, 1996, pp 121-126. o "NT 4.0 crash warning: Certify device drivers", Computerworld, June 17, 1996, pp 1, 131. Reports of bugs in Windows NT 4.0 have appeared. The article "NT 4.0 beta gets thumbs up for improved administration", InfoWorld, May 27, 1996, p 37 includes the following user feedback: ' (Briscoe) Stephens (a systems coordinator at the NASA Marshall Space Flight Center, in Huntsville, Ala.) expressed concerns, however, about whether Microsoft had fixed numerous bugs NASA detected in the first beta.' ' The second beta offers better network driver support, Stephens said.' The same magazine has a Product Review of Windows NT 4.0 Server Beta 2 in "NOS vs. NOS", InfoWorld, May 27, 1996, pp 1,102 which notes on page 102: ' Oddly Windows NT 4.0 Beta 2 was less stable than Beta 1 (see Product Reviews, Feb. 12, page 93) when running on the ALR Revolution Quad6 server from Advanced Logic Research, Inc., which won last week's comparison. (See Product Comparison, May 20, page 78). I found several severe memory leaks that ate up all available system memory in a matter of seconds and then crashed the system. Other times, NT refused to boot because it claimed that the Last Known Good menu had gone bad. Both of these problems could be attributable to beta device drivers.' These problems may be caused by bugs in the beta device drivers, bugs in the Beta 2 code of Windows NT 4.0 or a combination of these. As always is true of beta tests, users will need to wait until the product is generally available to assess how bugfree and stable the product itself is or is not. Microsoft continues to make changes to Windows NT 4.0 during the beta program, even after sending out 200,000 copies of Beta 2 in late May. In messages posted on the Compuserve WINNT forum in mid-June, one of the forum participants writes about these changes: 'certainly have changed things in the kernel etc.' 'all custom HALs will need to be recompiled. the IRQ handling etc in the HAL is totally changed. This means the Compaqs etc that use their own HALs will be late in the game unless they happen to have an office in Redmond.' These changes may or may not result in more bugs in NT 4.0 when it becomes generally available. Some of the points raised above, including the changes made to Windows NT 4.0 after shipment of Beta 2 are brought together in "Despite glitches, NT 4.0 is on track", PC Week, July 1, 1996, pp 1,97. More recently, an article about Microsoft releasing the NT 4.0 code to manufacturing on July 31, 1996 -- 'NT 4.0 beats clock', Computerworld, July 22, 1996, pp 1,109 -- notes continuing bug problems and user caution. On page 1, the article summarizes the condition of the final 'release candidate for NT 4.0: ' Although users of the prerelease version said they haven't encountered major flaws, some expressed concern that Microsoft may be shipping the product before addressing minor bugs and documentation woes.' On page 109, the article notes one user's current assessment of NT 4.0: ' "We won't install NT Server 4.0 in a production environment until at least the first quarter [next year], after the first service pack has shipped," said Bob Lee, senior manager at Charles Schwab & Co., a discount brokerage in San Francisco.' Conclusion ---------- In conclusion, only IBM OS/2 Warp Connect possesses all of these attributes that minimize the costs of upgrading to a 32-bit software platform. Microsoft Windows 95 and Microsoft Windows NT 3.51 each lack at least one of these attributes. This means that the costs of upgrading a computing environment from Microsoft Windows to either Microsoft Windows 95 or Microsoft Windows NT 3.51 will be higher than the cost of upgrading from Microsoft Windows to IBM OS/2 Warp Connect. Thus the best benefit to cost relationship results from upgrading Microsoft Windows environments to IBM OS/2 Warp Connect. I believe that both IBM and Microsoft understand this cost/benefit analysis. IBM has developed and now markets OS/2 Warp Connect. Microsoft seems unable to develop an operating system with all of these attributes. It is currently compensating for this weakness by pressing its current marketing advantage. In mid-1996, a Microsoft advertisement run in numerous personal computing magazines supports the analysis in this document and puts Microsoft's marketing perspective on it. The advertisement refers to using a mix of both Windows 95 and Windows NT Workstation because they have different strengths, which is seen in this document's analysis. The advertisement, on two facing pages, (e.g. PC Week, July 15, 1996, pp 77b,77c) shows on the left page a picture of two horses in a horse race with the statement above the picture: 'You see a horse race. We see two thoroughbreds.' The advertisement shows a picture of a box of Windows NT Workstation next to a box of Windows 95 at the top of the right page with the following text below the picture: 'A lot of other companies do, too. They're running both the Windows 95 and the Windows NT Workstation operating systems. Why? Because they want to realize the benefits of a more reliable, more manageable operating system. They also want to run the latest versions of their applications and take advantage of exciting new Internet technologies. That's why seven out of ten organizations have deployed (or are planning to deploy) Windows 95 and/or Windows NT Workstation; They know that both are safe bets.' ' The reason we developed both operating systems is twofold: First, to achieve maximum compatibility with our customers' existing hardware and software, and second, to provide them with an even more reliable and secure operating system.. Today, customers can run most of the same applications both across Windows 95 and Windows NT Workstation. And soom, with the release of Windows NT Workstation 4.0, both products will share the same user interface.' ' What's the right mix for your organization. That depends on what you need. Windows 95 is the easiest way to migrate to 32-bit Windows. It not only supports a third more hardware devices than Windows NT Workstation, it also has lower system requirements. Windows 95 also offers greater compatibility with certain MS-DOS applications. What's more, it has two functions that Windows NT Workstation, for the time being, does not: Plug-and-Play, and Power Management for Mobile Users. Windows NT Workstation on the other hand, offers greater reliability and security, thanks to its advanced microkernel architecture. It's simply one of the most powerful and robust 32-bit desktop operating systems you can get.' ' So if you thought you needed to hedge your bets, you don't, because this is no horse race. In fact, we will continue to support and update each product in the future since our customers continue to want both the broad compatibility of Windows 95 and the power of Windows NT Workstation.' 'For more help determining the best mix for your company, visit www.microsoft.com/windows/mix5/' ---- Attachment A ---- Windows NT Backwards Compatibility with Windows 3.1x Programs: Emulation and the Use of Insignia Solutions' SoftWindows Technology While Windows NT was under initial development, the first information appeared that it would use Insignia Solutions technologies in its emulation to support running Windows 3.1 programs. The information was a news item in Computergram, October 10, 1991: 'Microsoft Corp's vice-president of systems software, Steve Ballmer, says 16-bit Windows applications will be able to run under both the Intel Corp and MIPS Computer Systems Inc versions of its Windows NT operating environment: binary compatibility for existing Windows applications running on both will be provided by Insignia Solutions Ltd's SoftPC (sic) emulation software, which Microsoft recently licensed;...' The information about the use of emulation to support running Windows 3.1x on Windows NT was also part of the March 1994 Microsoft DevCast videoteleconference for developers. Shortly thereafter, the article "You Mean NT Can't Really Run Windows", Datamation, May 15, 1994, pp 67-68 was published. The Datamation article points out that Windows NT (note: article refers to Windows NT 3.1 -- which was generally available at the time the article was published -- as Windows NT 3.1 and Windows NT 3.5 by its pre-release code name 'Daytona') uses the Softwindows and SoftPC emulation technologies from Insignia Solutions to run 16-bit Windows programs. The Datamation article notes the following detail information about the Insignia Solutions' SoftPC and Softwindows technologies that Microsoft licensed for Windows NT in a sidebar: ' When NT is running on RISC machines using Alpha, Mips, or SPARC chips, for example, Insignia code emulates both the Intel x86 chip and MS-DOS operating system, as well as all of the hardware and drivers that Windows and DOS expect to call upon.' ' On Intel-based PCs, there's no need to use Insignia to emulate the x86 chip, of course. But Insignia still provides all of the Windows 3.1 and DOS drivers for the system hardware that make sure the 16-bit DOS and Windows applcations are isolated from direct contact with NT's protected Hardware Access Layer (HAL) or the hardware itself.' Further on, the Datamation article provides more insights into the development work done so that 16-bit Windows programs can run under Windows NT 3.5: 'Although Insignia's products play a crucial role in letting NT run 16-bit Windows 3.1 apps, Microsoft's own developers worked long and hard on the bulk of the 16-bit Windows emulation code. And they've kept on working long and hard of late to increase the speed at which the next version of NT (note: Windows NT 3.5) can run 16-bit Windows apps -- still, however, using Insignia's technologies. Microsoft developed a concept called "Win16 on Win32" (WOW) to enable 16-bit Windows apps to run under NT, even emulating a few Windows 3.1 coding errors in the WOW layer so that all of the applications written to expect those errors would be able to run.' In other words, Microsoft modified Insignia Solutions' Softwindows (note: Softwindows 1.0 was generally available when Windows NT 3.1 shipped) and SoftPC for use in the WOW subsystem/layer. Softwindows 1.0 supports "standard mode" Windows 3.1x programs, but not "enhanced mode" Windows 3.1x programs. Microsoft further modified this Softwindows 1.0 and SoftPC code for Windows NT 3.5. This code was further modified for NT 3.51 Some of the technical details of the WOW subsystem/layer were also published in the article titled "Test Drive Win32 from 16-bit Code Using the Windows NT WOW Layer and Generic Thunk" (Microsoft Systems Journal, June 1994, pp 13-40). On page 17, the author refers to emulation: ' Second, some new API calls have been added to the WOW versions of KRNL386.EXE, USER.EXE and GDI.EXE. Most of these functions appear to be there to internally aid WOW in emulating 16-bit Windows...' ' Third, and most importantly, the WOW code actually employed is significantly different from that found in a typical Windows 3.1 installation...' ---- Attachment B ---- The Design of Windows 95 and its Relation to Robust Multitasking In the Microsoft Windows 95 operating system, there is a single session for all 16-bit Windows programs and the 16-bit system components of Windows 95. The 16-bit system components of Windows 95 are modified versions of today's Windows for Workgroups 3.11 system components. The consequence of this design is that if one of the 16-bit Windows programs misbehaves (does not yield properly) and locks up this session, then the operation of all of the 16-bit Windows programs stops in Windows 95 -- just like Windows for Workgroups 3.11. In addition to stopping the operation of all of the 16-bit Windows programs, a single 16-bit Windows program that misbehaves will sooner or later also stop the operation of all 32-bit program pieces (threads) that use the 16-bit system components of Windows 95. According to Adrian King's book "Inside Windows 95", ('Internal Synchronization', pp. 149-155) the user interfaces of all 32-bit programs use ('thunk to') the 16-bit system components of Windows 95. Furthermore, according to testing that was published in Andrew Schulman's book, "Unauthorized Windows 95", (Chapter 13: 'Thunk! KERNEL32 Calls KRNL386) some functions of the 32-bit 'kernel' also use ('thunk to') the corresponding 16-bit system components of Windows 95. In other words, many -- perhaps most or all -- pieces (threads) of all (or maybe almost all) 32-bit programs use the 16-bit system components of Windows 95. Thus, all 16-bit Windows programs and parts of all (or maybe almost all) 32-bit Windows programs will stop sooner or later if a single 16-bit Windows program misbehaves (does not yield properly) while running under Windows 95. Furthermore, because many 32-bit parts of Windows 95 thunk to the 16-bit parts of Windows 95, the system may not multitask new 32-bit Windows applications well. Andrew Schulman has also written two articles for InfoWorld that analyze other aspects of the architecture of Windows 95 that may become problems in the future. The first article, "Vexed by VxDs" (February 27, 1995, pp 1, 53-58), says that Windows 95 systems may become harder to setup and increasingly unstable as more native Windows 95 programs are implemented that make use of virtual device drivers (VxDs). The second article, "New isn't necessarily better" (April 24, 1995, pp 65-69, 74), says that improperly written programs -- which could be DOS, 16-bit Windows or 32-bit native Windows 95 -- running on Windows 95 can accidentally change parts of Windows 95. Microsoft says that it has not observed this with any existing program. The article points out that new software might do this. Concluding Remarks The author, Jonathan Handler welcomes comments, constructive criticism and additional information. The author may be contacted via Compuserve: 71702,1620, or via the Internet: 71702.1620@compuserve.com.