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.

