Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!trwind!venice!press
From: press@venice.SEDD.TRW.COM (Barry Press)
Newsgroups: comp.windows.ms
Subject: Re: Strange memory errors in Windows?
Message-ID: <1113@venice.SEDD.TRW.COM>
Date: 29 May 91 19:38:20 GMT
References: <1991May29.005554.10290@cunixf.cc.columbia.edu> <1991May29.065802.22317@trl.oz.au> <1991May29.130902.17809@murdoch.acc.Virginia.EDU> <1991May29.175240.14589@cunixf.cc.columbia.edu>
Reply-To: press@venice.sedd.trw.com (Barry Press)
Organization: TRW Systems Engineering & Development Division, Redondo Beach, CA
Lines: 32

In article <1991May29.175240.14589@cunixf.cc.columbia.edu> mjf@cunixb.cc.columbia.edu (Michael J Flory) writes:
>
>More on the bad behavior of Windows in writing to floppies...
>
> ... A lot of notes deleted ...
>
>I think the problem occurred in full-screen DOS sessions as well as in a
>window, so I don't *think* that what Andrew Colfelt suggested -- that I
>might be losing time-slices in a windowed session -- is the answer.  (A

I'm not convinced that the complete point of the fix he suggested got
across.

In particular, running full screen DOES NOT by itself ensure that your
process does not get interrupted.  I can verify this by noting that a
clock (a WinApp) I use that beeps on the hour still beeps when I have a
full-screen DOS session going.

The other point he mentioned was to turn on EXCLUSIVE, either in the pif
or in the settings (Alt-space, settings, etc.).  While I haven't tested
that, nor have I recently RTFM'd on it, I believe that it's purpose is
to restrict the scheduler as he mentioned.

Having played with pre-emptive schedulers (which is what you have relative
to a DOS session, as opposed to within WinApps), I could believe that the
behavior you see when you cut down the memory is due to changes in the timing
of when the scheduler hits you.

It's at least worth trying ...

-- 
Barry Press                                 Internet: press@venice.sedd.trw.com