🚀 go-pugleaf

Andrew Colfelt kindly replied to my query about errors copying disks in Win3:

>mjf@cunixb.cc.columbia.edu (Michael J Flory) writes:

>>Some time ago I posted with a strange and dangerous error I got running
>>DISKCOPY in a DOS window with a .pif asking for all 640 K if it could get
>>it.  In short, the diskcopy operation miscopied a couple of sectors every
>>dozen-and-a-half or so (the number varied).  But although VERIFY was on,
>>I got no error message -- I discovered it through DISKCOMP.

>The best way to avoid this would be to run the DOS window full-screen.  It
>sounds a little like the floppy errors could be caused by the switching of
>CPU attention.  When you're 'multitasking' in Windows and performing a
>sensitive operation like copying sector-for-sector, the time-lag, skip,
>stutter, whatever, the window is causing a lack of proper 'attention' to the
>process and thus bytes are getting dropped.

>Try DISKCOPY in DOS, full-screen, and see if the problem goes away.  Better
>yet, try the window again, with the BackGround Box checked.  If the disks
>still lose bytes, try full-screen, BackGround.  One of these setups should
>allow the CPU to devote sufficient attention to the copying process to
>maintain good housekeeping on all bytes in all sectors.

Thanks very much for the advice.  When I read it I realized, though, that
I hadn't explained myself too clearly.  I carelessly interchange "in a 
window" and "in a windows session" and I did it here -- I *think* I ran 
things in full-screen when I got the errors.  I usually do just 'cause it's
faster.  But I am going to experiment a little and see if I can duplicate
the error in a window and out.  Also, I always check the "background" box
when I run things in the background -- as I usually run them full-screen.

The thing that struck me about the errors was their regularity.  In the
DISKCOPY problem, I got messed-up cylinders at regular intervals: for example,
cylinders 4, 5, 28, 29, 52, 53, ... might be bad (I'm making the numbers
up, and the intervals and exact values varied, but the patterning was of
that sort consistently).  In the (related?) problem copying files under
XTREE GOLD 2.0, the *beginnings* of the files were bad (it never started
in the middle of a file) and every other byte was wiped out, ending on a
nice even offset (e.g. 10000 hex).  That's why I started by looking for a
bad RAM chip.

I'll experiment a little more and follow up.  If Windows is allowing an
application to access more memory than it is really protecting, this could
be something nasty.  Oh -- yes, I am running a '386DX in Enhanced Mode.
I use Fastopen, Smartdrive, Himem, and Ramdrive in 4 megs of RAM, and aside
from too many device drivers I don't think there's anything exceptional
about my setup.

Again, thanks very much for the help!

Michael Flory (mjf@cunixb.cc.columbia.edu)