Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!maverick.ksu.ksu.edu!hoss!hoss.unl.edu!greg
From: greg@hoss.unl.edu (Hammer)
Newsgroups: comp.sys.apple2
Subject: Re: Suggestion re. System.Disk --> /RAM5
Keywords: WHY USE GS/OS FOR PLEBIAN COPYING JOBS?
Message-ID: <1990Aug10.235523.28079@hoss.unl.edu>
Date: 10 Aug 90 23:55:23 GMT
References: <11788@netcom.UUCP>
Sender: news@hoss.unl.edu (Network News Administer)
Distribution: comp
Organization: University of Nebraska, Computing Resource Center
Lines: 63

In article <11788@netcom.UUCP> avery@netcom.UUCP (Avery Colter) writes:
>A while ago, some people were posting about problems associated with
>loading the SYSTEM.DISK into /RAM5 with GS/OS, citing that the shutdown
>operation in the Finder tended to go haywire.
:
>Or, you can pack the entire system disk with ShrinkIt, and then, at any old
>whim, de-ShrinkIt the file into /RAM5.
:
>My favorite way of accomplishing all this, since it would take less disk
>space, would be to have my main disk boot into Copy II Plus v 9.0, from
>which I can duck into ShrinkIt. (If you don't have Copy II 9, make
>ShrinkIt itself the primary SYS file on a ProDOS 8 disk) Unshrink the
>GS.OS.SHK archive containing a compressed form of your SYSTEM.DISK into
>/RAM5. Change the boot slot in the Control Panel, and warm-start out of
>ShrinkIt. ShrinkIt won't be insulted in the least.
>
>One wonderful outgrowth of doing it like this, is that you can actually
>put an SHK file of SYSTEM.DISK on an 800K disk whose full size in /RAM5
>is probably over 1 Meg, which means you can have many of your favorite
>DAs, Inits, FSTs, and other cute little disk-hogging demons right at your
>disposal in /RAM5 along with the essentials, and all you have to do is
>order an unpack into /RAM5 and kick back for 60 seconds.
>
>A wonderful way to both increase speed and beat the 800K ceiling.

Oh, wait until your ShrinkIT file becomes corrupted!  I lost a backup of a
BBS like that.  If one block goes bad in that archive, you can kiss it
goodbye.  Plus a lot of programs will need that precious RAM you are using
for a RAMdisk.  If it is an 8-bit application, go ahead, it is great for
that.  You can store ProTERM (or ReadyLink) in it, you can use it as the
receive volume for xfers, at 800K it is perfect for making backups of
programs when you have only one 800K drive and the copier doesn't do
one-pass jobs on it.  But I don't suggest it for GS/OS programs, unless
you really know what you are doing.  (I've had problems copying a series
of files from a disk to /RAM5 from the Desktop.  It seems that since the
/RAM5 space isn't being used, we can load more stuff into memory before
saving.  Then it tries to save into /RAM5, and suddenly finds that it
can't, since it has used too much of it itself.  (ProTERM v2.1 has a
similar problem: if you save files in /RAM5, but stay online too long,
pretty soon your scrollback buffer starts overwriting your files, since it
doesn't reconfigure the scrollback capacity.  Is v2.2 like this?)

About Copy II+ v9.0:  I hate it.  I use v8.2 instead of v9.0.  V8.2 is
faster (sheesh, how long can v9.0 take to scroll-through/display a block
of a 3.5" disk in the sector editor) and that program-selector is a joke.
I get more use out of Bird's Better Bye than that thing.

In case you are wondering, I was shown v9.0 by someone else who owned a
copy, and decided that I didn't want to up(down)grade to it.

>-- 
>Avery Ray Colter    Internet: avery@netcom.uucp   | {apple|claris}!netcom!avery
>     o/~ Mama, mama, mama, keep those skinny girls at home,
>         o/~ `Cause this skinny boy wants a BIG FAT BLONDE!   - The Rainmakers

      __  ___________  __
     /_/\/_/_______\_\/\_\
     \ \_\ \__   __/ /_/ /
      \  __ \ | | / __  /
       \_\/\_\|_|/_/\/_/   Just call me "Hammer."
       / /_/ /| |\ \_\ \
      /greg@hoss.unl.edu\
     /_/ /_/_______\_\ \_\