Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uwvax!umn-d-ub!umn-cs!thelake!steve
From: steve@thelake.UUCP (Steve Yelvington)
Newsgroups: comp.sys.atari.st
Subject: Re: File transferring...
Message-ID: <1027891443342110@thelake.UUCP>
Date: 27 Nov 89 20:43:34 GMT
References: <9806@saturn.ucsc.edu>
Reply-To: pwcs.StPaul.GOV!stag!thelake!steve
Followup-To: comp.sys.atari.st
Organization: Otter Lake Leisure Society (MN-USA)
Lines: 59
X-Mailer: UUMAIL/Atari ST/TOS 1.0
X-Member-Of: STdNet, the ST Developers' Network
X-Snail-Mail: 1392 Brandlwood, White Bear Lake, MN 55110 USA

In article <9806@saturn.ucsc.edu>,
     dstr012@ucscg.UCSC.EDU (10003012) writes ... 

>Hello,
>  Does anyone out there know of or use a background uploading/downloading
>program that is either shareware or public domain.  I get on the net and
>download ALOT of things and it takes incredible amounts of time with a 
>1200 baud modem and background downloading would really be great.  Thanks
>in advance for any help.
>
>   Roman Baker
>   dstr012@UCSCG.UCSC.EDU

A "crippleware" program called STALKER was distributed on this network
many months ago; it may be available at the archive sites. The demo
version was limited to uploading (from you to a remote computer). To get
downloading capabilities, you had to send money to the programmer.

It looked pretty good. However, the background operation was based on
GEM pseudomultitasking. This means that any non-AES operations will bring
the background task to a screeching halt. For example, I could upload to a
BBS quiet easily while running GEM First Word, but as soon as I fired up
MicroEMACS, a compiler, or even a command shell, the system halted because
the foreground task had issued a blocking GEMdos system call (typically
Bconin or Cconin). Well-written GEM programs are supposed to do most of
their work by calling the Event Manager, which allows the background
process to have a crack at the system as needed, but most of the software
I use is non-GEM.

STALKER is a desk accessory, with all the limitations that accrue thereto.
As I recall, the size of the file to be transferred was limited by a static
buffer. The reason for this is that a GEM DA doesn't own any file handles;
they belong to the foreground task, as far as the operating system knows.
When a foreground task terminates, all files are closed and handles are
released. This is death to the DA if it is writing periodically to an open
file. Most DAs deal with the problem by doing only a single disk write.

I think the more appropriate solution would be to maintain an internal
record of the file pointer, and to Fopen/Fseek/Fwrite/Ftell/Fclose each
time the DA's own data buffer gets full. (This does leave the door open to
a horrible mess if the user or another program touches the file or even
changes a disk, but that's life.)

I think Eidersoft has marketed a commercial background file-transfer
utility, but I have not seen it advertised in a long time.

I would like to see someone write a generic background file-transfer
utility with a well-documented interface that could receive instructions
from other programs using the GEM AES message-passing facility. Any
volunteers? I'd love to do it myself, but I'm sort of tied up with some
other stuff at the moment.

Of course, if Dave Beckemeyer releases RTX as he has hinted, the whole
issue could become moot -- a program could spin off a real background file
transfer process and not have to worry about living under the Event
Manager's thumb.

   -- Steve Yelvington, up at the lake in Minnesota        
  ... pwcs.StPaul.GOV!stag!thelake!steve             (UUCP)