🚀 go-pugleaf

In article <1.22EEA4B4@rubbs1.UUCP> Chris_Tuttle@rubbs1.UUCP (Chris Tuttle) writes:
>
>      Well I find Shadow useless anyway.Mostly because you need more then a meg for real use of the program.If you download more then your buffer takes,TOO BAD IT ABORTS THE WHOLE THING! and most of my files are more then 400k which is the most memory I can handle on my 1-meg  520.But Shadow first  says its initializing then sorta crashes and say that shadow is installed most likely SHADOW.INF isn't installed on the MAIN directory of your current drive(Mines drive C: because I boot from Hard Drive)

Dear Chris:

	Plz read your manual.  SHADOW does not crash, but performs a cold boot
in order to setup the reset-proof transfer area.  This is necessary to allow
SHADOW to continue up/downloading even after you press the RESET button, switch
monitors, or change rezs.
	Not having SHADOW.INF on the root level makes no difference what-so-ever
to SHADOW.  SHADOW has built-in defaults to overcome such deficiencies.  In
addition, you can have a desktop icon for SHADOW (in place of SHADOW.INF).
	I agree that SHADOW will put the pinch on 520K systems, because of the
need to have the file transfer buffer.  However, in order to allow SHADOW to
run during any program (.tos, .ttp, or .prg) means that you must have some
place to save your data because you can not easily perform disk I/O on the
interrupt level.
	If you are familiar with Interlink's 'background' file transfers, then
you know the limitations of virtual spooling to disk, ie. you can only use
GEM programs while up/downloading, and when it accesses the disk (via the desk
accessory) the system halts completely.
	Interlink's next version will allow background transfers during all
programs (supposedly) and will use a concept similar to ours, ie. a buffer
to hold the largest expected file.
	In order for us to provide virtual file spooling to disk, we would have
to rewrite ALL disk drivers to be re-entrant, and provide for a method of
collision avoidance when the foreground program wants the disk, but the
interrupt program (SHADOW) is using the disk (or vice-versa).
	We are working on disk I/O during interrupts, but TOS is not the best
to patch up in this area.  And thinking of all possible scenarios is quite a
challenge, especially when dealing with interrupt level programming.
	Sorry if I sound like I am flaming, but we HAVE (despite some beliefs)
put much time, thought, design, and sweat into SHADOW.

	BTW - I hate seeing the replies before the real message.. damn usenet
	BTW-BTW - For all you SHADOW owners, look for a patch program posted
		here this weekend (upgrades to 1.01)

- Mike

-- 
for (;;)                              : Use ATARINET, send an interactive
        do_it(c_programmers);         : message such as:
                                      : Tell UH-INFO at UHUPVM1 ATARINET HELP
University Atari Computer Enthusiasts : University of Houston UACE