Path: utzoo!attcan!ncrcan!becker!censor!comspec!tvcent!lethe!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!uw-beaver!sumax!polari!georgf
From: georgf@polari.UUCP (George Forsman)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Where is Windows 386 3.0?
Message-ID: <1978@polari.UUCP>
Date: 7 May 90 01:32:13 GMT
References: <4008.263c5a65@vax5.cit.cornell.edu> <5190090@hplsla.HP.COM>
Reply-To: georgf@.UUCP (George Forsman)
Organization: PolarServ, Seattle WA
Lines: 68

In article <5190090@hplsla.HP.COM> davidr@hplsla.HP.COM (David M. Reed) writes:
> [material regarding MS supplied memory manager deleted for brevity]

>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

The general idea is to write the device driver so that it can make use of
high memory itself.  This is much cleaner, and does not require the overhead
of a yet another memory manager to handle interrupts destined for the driver.
The XMS spec details how this can be done.  I agree, however, that in todays
memory-tight environment, large TSRs/drivers should be placed outside of
transient program memory.

> [stuff about win3.0 removed for brevity]

>
>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.

"Microsoft's concept of multitasking" that you quote above is true for windows,
but not for os/2.  Windows uses "non-preemptive multitasking" relying on the
application to give up control to the operating system.  I'm not certain for
the reasons behind this, but they are likely to have been forced by the need
to support 8086/8088 hardware.  I guess that Win 3.0 could have been designed
to use preemptive multitasking for windows applications, and in fact it might.
Win/386 does do pre-emptive multitasking between windows itself, and any DOS
applications running under it.
  I believe that the reason for not adopting VCPI was that it did not provide
a secure multitasking environment.  That is, it would allow applications to
access memory that did not belong to them.  This may be acceptable under DOS,
but cannot be allowed under OS/2.  I don't think Microsoft would want to
promote something that was not going to be available under OS/2.

>
>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).

Hopefully there will be a movement to unify the standards, or at least let
them coexist in peace.  It may seem that Microsoft has gone off on a tangent,
but I'd like to suggest the possibility that maybe they _did_ think about
all of this, and found that the current methods did not suit long-range
plans.  With new technology there seems to be a period of confusion before
the dust settles and standards emerge.  Hopefully all parties involved will
work together to bring about a solution that benefits all.


-- 
George Forsman  |  georgf@polari.uucp | "I know that you think you understand
...!uw-beaver!sumax!polari!georgf     | what you thought I said, but I am not
--------------------------------------| sure you realize that what you heard
Disclaimer: Ask me! I'll deny it!     | is not what I meant."