Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!cs.utexas.edu!sdd.hp.com!hp-pcd!hplsla!davidr
From: davidr@hplsla.HP.COM (David M. Reed)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Where is Windows 386 3.0?
Message-ID: <5190090@hplsla.HP.COM>
Date: 5 May 90 01:02:16 GMT
References: <4008.263c5a65@vax5.cit.cornell.edu>
Organization: HP Lake Stevens, WA
Lines: 42

One writer complains, rightfully in my opinion, about the loss of benefits
derived from such Expanded Memory Managers as QEMM and 386^MAX if the new
MSWindows 3.0 is to be used in all its glory.  Another user pointed out that
an Expanded Memory Manager is provided with MSWindows.  Unfortunately, that
Expanded Memory Manager is, in my opinion, simplistic.  Perhaps the second
user did not understand what is lost by MSWindows' EMM instead of using QEMM 
or 386^MAX: the ability to load device drivers and TSR's into the memory
region between 640K and 1MByte.  

This can be a critical point, especially if you have network drivers, which
often take 100K of RAM.  If, after loading the operating system (including
your standard device drivers and any necessary TSR's) you only have 475K of
conventional RAM left, then the largest "vitual" machine (window) you can 
have under MSWindows 3.0 is approximately 470K.  This is not a problem if 
the large programs you want to run are written for MSWindows (e.g. Excel),
but this is too small for several large non-Windows products, requiring the
user to exit MSWindows if they need to run their special application.  (And
thus robbing the user of much of the benefits of having a windowing operating
system.)

I was very interested in MicroSoft's stated reasons as to why they would not
adopt the Virtual Control Programming Interface (VCPI) that 95% of the rest
of the industry seemed to be agreed upon for managing multiple protected-mode
programs at one time (such as Paradox and MSWindows).  A primary reason was
because it lacked what they felt were appropriate means for handling multi-
tasking!  And this from a company that has yet to learn how to do multi-
tasking properly!  (Their concept being that the primary (foreground)
application running is considered "real-time" and therefore has ultimate
control of the cpu.  Meaning that only if the foreground application gives
up some of its cpu time will any background tasks get any.)  This reason
for not adopting VCPI seemed very strange, especially since another company
who does provide a real multi-tasking environment (Quarterdeck, with DESQview)
is a supporter of VCPI.

At least I would like MicroSoft to have pointed out shortcomings of VCPI that
need to be addressed, and then enhanced (or created a superset of) VCPI to
satisfy those needs.  That way MSWindows 3.0 could run with other protected-
mode programs (including the extremely valuable QEMM and 386^MAX).  But, no,
they have to do it THEIR way.  And I believe most users will suffer from
that decision (at least for a couple of years, until things become better
resolved, and new versions of programs come out that deal properly with this
issue).