Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!rex!ames!haven!mimsy!mojo!burgoyne
From: burgoyne@eng.umd.edu (John R. Burgoyne)
Newsgroups: comp.windows.ms
Subject: Re: Yyyaaawwwnn.......delays when downloading in background
Keywords: PCPLUS, Spam, DSX, Spam, Windows, spam eggs and spam
Message-ID: <1991Jan1.071606.928@eng.umd.edu>
Date: 1 Jan 91 07:16:06 GMT
References: <26117@uflorida.cis.ufl.EDU> <19771@netcom.UUCP>
Sender: news@eng.umd.edu (C-News)
Distribution: comp
Organization: College of Engineering, Maryversity of Uniland, College Park
Lines: 27

Actually, the problem is that whenever a program other than the comm.
program needs to do disk I/O, the cooperative multitasking ends.

Under DOS, no matter how you try, there is no way I've found to have
a secondary program do disk I/O while a comm program is doing a file
transfer, without having the comm program hiccup or terminate the file
transfer.

A big RAMDRIVE might help, since the I/O is so fast the comm program
may not notice, but I haven't tried this.

I use XTALK for windows and Procomm.

I usually just curtail windows activities which would need to do file
I/O while a file transfer is in progress.

WINDOWS DEVELOPERS PLEASE NOTE

Do not write programs in such a way that they do file I/O as a passive
action without intervention from the user, or the ability for the user
to turn the passive file I/O off since you may screw up the user's file
transfers.

OS/2 and UNIX don't have this problem due to the preemptive nature of 
their multitasking.

Robert