Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu!mjf
From: mjf@cunixb.cc.columbia.edu (Michael J Flory)
Newsgroups: comp.windows.ms
Subject: Re: Strange memory errors in Windows?
Summary: Relation of errors to winmemsize
Message-ID: <1991May29.175240.14589@cunixf.cc.columbia.edu>
Date: 29 May 91 17:52:40 GMT
References: <1991May29.005554.10290@cunixf.cc.columbia.edu> <1991May29.065802.22317@trl.oz.au> <1991May29.130902.17809@murdoch.acc.Virginia.EDU>
Sender: usenet@cunixf.cc.columbia.edu (The Network News)
Reply-To: mjf@cunixb.cc.columbia.edu (Michael J Flory)
Organization: Columbia University
Lines: 64
Nntp-Posting-Host: cunixb.cc.columbia.edu


More on the bad behavior of Windows in writing to floppies...

I just read Raul Baragiola's post saying he'd had problems similar to mine
writing to floppies in a DOS session under windows, and I'm putting that
together with Tony Stevens' comments on how excluding his video memory helped.
As I mentioned, my notes on the first problem (DISKCOPY in a DOS session)
were trashed by the second problem (XTREE GOLD 2.0 wrote my notes to a floppy
with many sectors missing every other byte)!  But I now recall that a sort
of fix was to either reduce the size of the memory my COMMAND.PIF asked for
(I made my own to get around the small amount of memory the DOS icon in
the Main folder gives me, and asked for all 640K if available) OR to reduce 
the amount of memory allocated to Windows by specifying a value under 640K
for the winmemsize variable in the [win386] section of WIN.INI.  There seemed
to be a maximum allowable COMBINED size for the two -- in my case, about 1Meg.
This seemed to prevent the bad DISKCOPY's in my DOS session.

At this juncture, my suspicions are narrowing as follows:

My floppy drive behaves perfectly otherwise, so I rule it out.
My RAM passes both the POST and a diagnostic RAM test, so it seems OK.
(If I were using memory interleaving I would be more suspicious of the RAM,
as that could explain the every-other-byte-bad pattern.)
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
consultant at Columbia's computer center, TJ Lee, also suspected a timing
problem, with another application stealing slices at the wrong time, but 
I think the problem is too *regular* -- in DISKCOPY, the pattern of trashed
sectors was two sectors every X sectors, probably implying two bad sector 
copies every disk swap.)
I'm using only a 256K video adapter (tho' it is superVGA capable -- Video7
1024) and I'm in 16-color mode, so I don't *think* that's it.

It looks like Windows is misallocating memory to DOS tasks, then, giving
the sessions more memory than it is really protecting.  I don't understand
the intimacies of memory protection in the 80386's virtual 8086 mode, but
it looks like Windows is possibly writing over some of the memory itself,
as it, at least, is always active (with the DISKCOPY problem, at least, not
much else was going on when it screwed up).  This occurred only in DOS
sessions begun with a .pif file; oddly, though I listed a .bat file in my
run line in WIN.INI, Windows ran my .pif file for Windows anyway.  This .pif,
like the one for the command line, asked for 640K if it could get it.  I
recall trying all sorts of other combinations in the "advanced" section of
the PIF editor to no avail.

After the DISKCOPY problem showed up I looked into alternatives to DISKCOPY.
But with the XTGOLD problem and other suspicious behavior (DOS session apps
getting at other DOS apps' memory, etc.) I am going to reduce my winmemsize
to 448K (as I recall that didn't slow things too badly, surprisingly) and
see if I can avoid asking for more than 512K in .pif, less if possible.  
(That'll spare me a little swapping, too, I hope!)  Meanwhile, I'm looking
into OS/2 2.0 -- sounds like even the beta might give better virtual process
protection.

Thanks to all who have helped me with this mess -- and by saying that I don't
mean to cut the discussion thread short here, any more ideas or experiences
would certainly interest me.  One final note: I learned the hard way that
VERIFY ON apparently doesn't affect disk writes under anything but COPY!
_____________________________________________________________________
Michael Flory (mjf@cunixb.cc.columbia.edu)
"Yes, the computer did arrive "just in time."  But in time for what?"
                -- Joseph Weizenbaum, Computer Power and Human Reason
_____________________________________________________________________