🚀 go-pugleaf

In article <8905231618.AA24695@ucbvax.Berkeley.EDU>, 01659@AECLCR.BITNET (Greg Csullog) writes:
> Once again, for those who missed earlier postings, STOP using the AUTO folder
> to load all your boot-time codes in during startup. It makes much more sense
> to use the batch file processor STARTUP.PRG (see sample listing below) to
> run codes from any pathway. If you precede a code call with 'ask' you will
> be issued a prompt to confirm or cancel execution; save yourself a lot of
> grief with infinite reboots when you put a crappy code in AUTO.
> 
> Simply put STARTUP.PRG and STARTUP.INF in your AUTO folder. When you want to
> add more codes, just insert a call to them in STARTUP.INF. Why mess around
> with the order of files in AUTO?
> 
> You can get STARTUP.PRG from Accusoft's PD library.
>
[ Sample deleted ]

This is a rather broad generalization, and one that is a dangerous one to make.

The problem is that many programs that are put in the /auto directory are of
the "Terminate and stay resident" (TSR) variety.  Running these from a batch
processing program such as STARTUP.PRG creates a gap in memory when STARTUP.PRG
terminates.  The program is loaded above STARTUP.PRG and stays in memory.
I have no direct experience with STARTUP.PRG, but if it does further Mallocs
after running your TSR, it may screw things up by assuming that it owns memory
between the end of its old block and the beginning of the new one.

Programs like STARTUP.PRG are good for running programs like clock setters,
some RAM disks, and the like, but should not be used for programs like
the hard disk driver, screen-savers, folder limit fixes, resident debuggers,
font switchers, OS call tracers, GDOS, disk caches, and other resident
programs of that sort.

I have a DANGEROUS program which can be used to reorder the files in
a directory, get rid of empty entries in the middle and mark the ones
at the end as unused (to speed up directory searches) rather than deleted.
I have used this program without any problems since I got it working, but
if ANYTHING goes wrong while it's doing its dirty work, look out!
I will submit this program (and source) to comp.binaries.atari.st and
comp.sources.atari.st sometime in early June (I'm going on a vacation soon
and don't have time to dig it out just now.)  Note that this program has
not been tested under TOS 1.4.

					Daniel A. Glasser
-- 
 _____________________________________________________________________________
    Daniel A. Glasser                           One of those things that goes
    uwvax!per2!dag                              "BUMP!!!(ouch)" in the night. 
 ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------