OS/2 Shareware BBS: 36 Tips/36-Tips.zip/pcos96c.txt

Text File | 1996-09-26 | 49KB | 944 lines

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: [e-mail].