Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!cci632!srw
From: srw@cci632.UUCP (Steve Windsor)
Newsgroups: comp.windows.ms
Subject: Re: WIN3 Enh mode fails on EMS de-allocation, WHY??
Keywords: win3 ems
Message-ID: <54940@cci632.UUCP>
Date: 5 Mar 91 19:41:52 GMT
References: <555@shograf.COM>
Reply-To: srw@op632.cci.com (Stephen Windsor)
Organization: CCI, Communications Systems Division, Rochester, NY
Lines: 63

In article <555@shograf.COM> jim@shograf.COM (jim morris) writes:
>it appears that windows 3 in 386-Enhanced mode  running a DOS window fails when
>EMS memory is de-allocated. Microsoft Tech support hinted that
>EMS support is limited in some way. Why would Microsoft not do a full EMS emulation??
>Does anyone else know what this problem is??
>
>Any comments anyone?
>
>-- 
>Jim Morris,	E-Mail: jim@shograf.com    Voice: (415) 903-3887
>  _ 
>SHO graphics.	Practical PEX

Yes.
This is a major bug from Microsoft, IMVHO.
My project has come across somewhat of a stumbling bug, because of this.

I am using Win 3.0A in enhanced mode. in enhanced mode.
I am running AT&T Starlan Network.
If I load the network data into low memory, I don't have enough room
  left over for the MSC 6.00A compiler to run; so, I load the
  Windows expanded memory manager (device = c:\win30a\emm386.sys xxx).
  Starlan will store the network data up in expanded memory.
All well and good, until I run Win/3 (windows in enhanced mode) -- the
  network data in expanded memory is trash!!

Why -- I'll tell you, and I took 2 calls to MS support to find out.

When running in enanced mode, Windows loads its own expanded memory manager
REGARDLESS IF THERE AN EMM DRIVER ALREADY INSTALLED.  What is supposed to
happen, BUT DOES NOT, it that the windows emm will save the state of the
64k frame of the current emm driver, tell that emm driver to shut down,
and then incorporate the first emm state into its emm driver.  However,
the state (and thus the data) of the first emm driver IS NOT SAVED.
(Note:  the EMMxxxxxxx switches in the SYSTEM.INI file (See sysini2.txt)
work on the internal Expanded memory manager characteristics, not the
EMM386.SYS previously loaded in CONFIG.SYS.)

I can accept that this is a bug (albeit a sizeable one).  A system
the size of Windows will have bugs.  What I found unacceptable, though,
was what the second MS Tech Support person told me:

  1)  MS did not want to advertise this particular bug, and therefore:

  2)  There was no mention of the bug in their database.  This person
      knew it (whereas the first did not) only because he was more
      experienced.  He could not send me any documentation at all on
      this bug, so I had only his word to take to my superiors.

  3)  He was unsure about whether this bug would be fixed in 3.1.

I know this bug does in fact exist, because my supervisor's disk got
trashed after he attempted to save his network state based on the
trashed data in expanded memory.

MS recommended using an extended memory manager, such as Quarterdeck's
QEMM386.sys...but Starlan doesn't use extended memory, so I'm stuck.

Check your app...is it using expanded memory? If so, this may be the cause.

Sorry about the gripe, but I think MS handled this one poorly.

Stephen Windsor   srw@op632.cci.com