dstr012@ucscg.UCSC.EDU (10003012) (11/19/89)
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
steve@thelake.UUCP (Steve Yelvington) (11/28/89)
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)
uace0@uhnix2.uh.edu (Michael B. Vederman) (11/30/89)
Steve Yelvington basically states that he wishes someone would write a 'generic' background file transfer program that would have a message pasing system to start transfers (or some such). Steve: SHADOW (our product sold by ANTIC) does just that. It completely works in the background (during .PRG, .TOS and .TTP programs) and can even survive system resets and still keep the file transfer going. It doesn't slow the machine down, and is 99.5% compatible with software out there. The calling sequences to access SHADOW are well documented, and we even provide source code libraries in ASM and GFA BASIC, and a .O file to link with for even easier access. Several PD/SHAREWARE terminal programs and FLASH! have support built-in. Heck, even GULAM could have the calls built-in (if he put them in there). SHADOW is 100% assembly and is FAST! I would venture to say that it is about the most efficient file transfer program out for the ST (CPS thruput). Hope that helps. SHADOW retails for $29.95, but we can send it for $20. Sorry for the advert... - mike -- ------------------------------------------------------------------------------ Double Click Me | Double Click Software | P.O. Box 741206 | Houston, Tx, 77274 ------------------------------------------------------------------------------ Support BBS: (713)944-0108 | SHADOW | DC FORMATTER | DC UTILITIES | and others
logic@wet.UUCP (Henry Kwan) (12/01/89)
In article <919@uhnix2.uh.edu> uace0@uhnix2.UUCP writes: > >SHADOW is 100% assembly and is FAST! I would venture to say that it is about >the most efficient file transfer program out for the ST (CPS thruput). > >- mike > Mike, Does Shadow support a full implementation of Zmodem yet? With 32-bit CRCs, error recovery and all those other goodies that Mr. Forsberg crammed into his protocal perhaps? How about Ymodem-G? Does any ST program support this protocal yet? -- Henry Kwan | AppleLink: D0690 FWB, Inc. | CompuServe: 71320,1034 2040 Polk St. Ste 215 | Internet: claris!wet!logic@ames.arc.nasa.gov San Francisco, CA 94109 | UUCP: {claris,hoptoad,lamc,ucsfcca}!wet!logic
bright@ccu.umanitoba.ca (Bob Bright) (12/09/89)
In article <1027891443342110@thelake.UUCP> pwcs.StPaul.GOV!stag!thelake!steve writes: >> 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. > >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. I've been using STalker for all my communications for a year or so, and recently upgraded to v2.03. STalker is a desk accessory terminal emulator (vt52/100) which features a very flexible background autodialer (handy when you don't want to tie up your system trying to get onto a busy system), a scrollable virtual screen which is configurable to any size you want, limited function key macros, and ASCII/Xmodem/Xmodem-1K uploads and ASCII/Xmodem/Ymodem-batch downloads in the background with any GEM application. The most recent version also includes STeno, a basic text editor accessory with hooks into STalker. (I don't use it myself, since I spend most of the day in Word Perfect.) The main reasons I use STalker are: I really like having my communications program a mouse-stroke away; being able to view my terminal session in one window while using Word Perfect in another (as I'm doing now) is great; and being able to download large files without tying up my machine for hours is a godsend. I think I paid $35 Cdn for the original version, and $15 for the upgrade. A couple of comments on Steve's comments: >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 Right; STalker will not work in the background with most non-GEM applications. (It _will_ run in the background with the most recent version of MicroEMACS, however; I can't remember the version number, but it's the one that uses the mouse. Not sure we can generalize here, but any application which uses the mouse should be a good bet for use with STalker.) This isn't really a problem for me, since as I mentioned, I spend most of the day in Word Perfect. But be forewarned. >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; Nope. I think you must be confusing STalker with Shadow, Double Click Software's background transfer utility. Shadow requires you to allocate a fixed amount of buffer space at startup, and writes to disk only when the transfer is complete. This has the advantage of making transfers "reset-proof", but the disadvantage of tying up large amounts of memory, particularly when you anticipate downloading large files. By contrast, STalker writes to disk whenever its transfer buffer is full, and can be configured with a transfer buffer as small as 4K. (BTW, the most recent version of STalker takes advantage of Shadow's hooks, so you can use Shadow's background routines with STalker if you really want to. It also supports Double Click's multiple rs232 port gizmo, so if you've got a pair of modems you can install two copies of STalker, and have two terminal sessions running in the background at the same time! It can also be configured to work with the midi port, though whether this would allow hanging an additional modem off the midi port is beyond me.) As an accessory, STalker does use memory. A minimum configuration burns about 90K. This still allows me to allocate a 200K ramdisk at startup and run Word Perfect with room to spare on my unadorned 1040ST, so I can't complain. SO: If you spend a lot of time in non-GEM applications and don't mind setting aside a large chunk of RAM at startup, check out Shadow. If you use mostly GEM applications and like the idea of having background communications at your fingertips, I highly recommend STalker. Make no mistake: STalker is nowhere near as full-featured as Uniterm or even Flash. I used to be a die-hard Uniterm user, and never thought I'd be tempted to use anything else; but STalker is so damn handy (for me!) that I haven't dusted off my Uniterm disk in months. STalker is written by Eric Rosenquist and marketed by: Strata Software 94 Rowe Drive Kanata, Ontario, Canada K2L 3Y9 (613) 591-1922 Needless to say, I have no pecuniary interest in Strata Software (or anything else for that matter, if my bank account is an indication). BBB -------- Bob Bright <bright@ccu.umanitoba.ca> Dept. of Philosophy 452A University College University of Manitoba Winnipeg, Manitoba R3T 2N2 (204) 474-9680