Xref: utzoo comp.os.msdos.apps:2168 comp.windows.ms:13813
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!microsoft!bobsc
From: bobsc@microsoft.UUCP (Bob SCHMIDT)
Newsgroups: comp.os.msdos.apps,comp.windows.ms
Subject: Re: MS-DOS v5.0 Release Date 11th June
Message-ID: <72917@microsoft.UUCP>
Date: 14 Jun 91 20:15:27 GMT
References: <gurganus.675797385@stable.ecn.purdue.edu> <1006@macuni.mqcc.mq.oz> <72798@microsoft.UUCP> <6669@gssc.UUCP>
Reply-To: bobsc@microsoft.UUCP (Bob SCHMIDT)
Organization: Microsoft Corp., Redmond WA
Lines: 67

I wrote:

  As for the conflict between DOS 5 UMB support and Windows '286 mode...
  You're not hallucinating; the conflict is real.  Windows detects that
  some other protected-mode software is running, and won't load.  I can't
  say if/when this conflict will go away.

Tim Roberts responded:

  Bob, is this the official Microsoft position, or are you speaking on your own?
  Your last sentence shows extreme short-sightedness and a lack of understanding
  of the seriousness of this problem.
 
  Why was this incompatibility allowed to happen?  This failure in DOS 5 nearly 
  makes it unacceptable for Windows developers.  Our drivers have to work in 
  EACH of the Windows modes.  Now, running DOS 5's EMM386, I can no longer test 
  Standard mode.
 
  QEMM happily coexists with Windows in Real, Enhanced, AND Standard modes.  
  If Quarterdeck can achieve 386 memory detente with your OS and your
  window manager, then surely Microsoft itself should be able to do at least
  as good a job!
 
  This is a SIGNIFICANT deficiency.  I sincerely hope Microsoft is making more
  of an effort to isolate and correct this flaw than is indicated in your mail.

My reply:

  I am speaking on my own.  I should have stated such in my signature,
  and aplogize for the confusion.  I have ammended my signoff to reflect
  this.  I was not stating any official Microsoft position, but rather
  simply confirming someone else's observation.  The "Microsoft"
  in my signature lets readers know who/where I am; it does *not*
  imply an endorsement of my words by MS.

  As an employee of Microsoft Product Support, I am quite limited
  in what I'm allowed to discuss in a non-confidential forum, such
  as this.  Other parts of the company may enjoy more freedom; I don't.
  When I post something to UseNet, even in a "non-official" capacity,
  I have a sometimes ill-defined line I cannot cross.  Trust me, I
  wish it were otherwise.

  I figure it's better to say something than nothing at all.  In my
  former life, I was a Microsoft customer; I want to help you.
  Please know that I'm operating in "good faith" for both you all and MS.

  Now, concerning EMM386...I can honestly tell you that both Windows
  Development and DOS Development are looking at it.  There is no
  word yet on a fix.  I don't know why this was "allowed to happen".
  My conjecture is that Windows was not written with DOS 5 in mind,
  and that the DOS people felt the plus of UMB outweighed this minus.
  The file WINA20.386 falls into this same category, as a work-around
  for Windows not expecting DOS to mess with the A20 line.

  My educated guess is that we will fix this in the next release of
  Windows (along with obviating WINA20.386).  Note that the conflict
  only arises when you use EMM386 for UMB support.  You can turn
  off UMB, and the problem will go away.  This will at least allow
  you to run in standard mode, although maybe not under the memory
  configuration you would like.
--
--  NOTE:  The above is mine alone; I do NOT speak for Microsoft.
--
--  Bob Schmidt        bobsc@microsoft.UUCP
--
--  Bellevue WA USA    Windows SDK Support
--  Sydney NSW AUS     Developer Support (after 1 Oct)