A USER VIEW ON BENEFITS AND COSTS OF UPGRADING TO IBM OS/2 WARP, MICROSOFT WINDOWS 95 AND MICROSOFT WINDOWS NT 3.51 October 1995 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 32-bit preemptive multithreaded multitasking operating systems: IBM OS/2 Warp, Microsoft Windows 95 and Microsoft Windows NT 3.51. 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: IBM OS/2 Warp uses modified Windows 3.1 code. 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.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 October 2, 1995, more than one month 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: 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. Some of the technical details of the WOW subsystem/layer were 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...' According to the article "You Mean NT CAN'T Really Run WINDOWS", (Datamation, May 15, 1994, pp 67-68), the Microsoft Windows NT 3.51 Windows on Windows subsystem uses Insignia Solutions Softwindows technology that emulates Windows 3.1. (see Attachment A). 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. 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 4 MB or 8 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 standalone personal computer (i.e. a personal computer not connected to a local area network) using the operating system must run with acceptable speed with a DOS or small Windows program in 4 MB RAM. The user minimizes memory hardware upgrade costs. 2.a. IBM OS/2 Warp: IBM OS/2 Warp on a standalone personal computer can do this. IBM specifies OS/2 Warp's minimum memory requirements to be 4 MB RAM. 2.b. MS Windows 95: Microsoft Windows 95 on a standalone personal computer can do this. Microsoft specifies Windows 95's minimum memory requirements to be 4 MB RAM. 2.c. MS Windows NT 3.51: Microsoft Windows NT 3.51 has been widely reported to require 12 MB RAM minimum with even a small 16-bit Windows program and therefore does not possess the minimal hardware upgrade attribute. Microsoft specifies Windows NT 3.51's minimum memory requirements to be 12 MB RAM on personal computers based on Intel 80386 and above microprocessors. 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 Network Standalone Standalone Connection Minimum Workable Sweet Spot Memory Memory Memory IBM OS/2 Warp 4 MB RAM 8 MB RAM 16 MB RAM MS Windows 95 4 MB RAM 8 MB RAM 16 MB RAM MS Windows NT Workstation 3.51 12 MB RAM 16 MB RAM 32 MB RAM 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. 3.a. IBM OS/2 Warp: 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 Backwards Compatibility with DOS and Windows 3.1 Programs, Section 1 of this analysis, OS/2 Warp subsection). 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: 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. 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 helps the user minimize support costs. 4.a. IBM OS/2 Warp: IBM has trademarked this 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. 4.b. MS Windows 95: Microsoft Windows 95 does not possess the robust multitasking attribute. A dramatic example of this was relatedd in "Of COM Ports and Digital Frogs", (Byte, September 1995, pp.___-___) 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 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 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 "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". 4.c. MS Windows NT 3.51: On the other hand, Microsoft Windows NT 3.51 has the robust multitasking attribute because of its design. 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.' Conclusion ---------- In conclusion, only IBM OS/2 Warp 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 Windows 95 or Microsoft Windows NT 3.51 will be higher than the cost of upgrading from Microsoft Windows to IBM OS/2 Warp. Thus the best benefit to cost relationship results from upgrading Microsoft Windows environments to IBM OS/2 Warp. I believe that both IBM and Microsoft understand this cost/benefit analysis. IBM has developed and now markets OS/2 Warp. 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 fact, it is so aggressively pressing its marketing advantage that the United States Department of Justice is continuing its investigations of Microsoft. ---- Attachment A ---- "You Mean NT Can't Really Run Windows." (Datamation, May 15, 1994, pp 67-68). OS/2 Warp has superior backward compatibility with 16-bit Windows application programs when compared to Windows NT 3.51. OS/2 Warp uses modified Microsoft Windows 3.1 code, which Microsoft licensed to IBM as part of the 'divorce settlement' between the two companies, to run 16-bit Windows programs. The Datamation article includes the following information about OS/2's support of 16-bit Windows 3.x applications: ' Incidentally, it's been more than two years since five or six young programmers at IBM's Boca Raton labs figured out a way to run 16-bit Windows 3.x apps on IBM's then-new 32-bit OS/2 2.x OS in native mode. And they pulled it off in less than three months.' On the other hand, the Datamation article points out that Windows NT 3.51 (note: article refers to earlier 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 information about the use of emulation in the Win16 on Win32 (WOW) subsystem in Windows NT was also part of the March 1994 Microsoft DevCast videoteleconference for developers. Even earlier, it had been 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 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.' The Datamation article notes that Insignia Solutions' technologies are also used by other operating systems: 'Insignia Solutions' SoftPC and Softwindows emulation products are generally used to run DOS and Windows 3.1 applications on RISC-based Unix workstations and Mac PowerPCs. Insignia also sells a version of Softwindows for the Nextstep for Intel operating system.' ---- 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 does 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.