Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!pacbell!hoptoad!peora!cmpfen!bob
From: bob@cmpfen.UUCP (Bob Breum)
Newsgroups: comp.sys.atari.st
Subject: Re: AUTO folder
Message-ID: <210@cmpfen.UUCP>
Date: 25 May 89 10:57:51 GMT
References: <8905231618.AA24695@ucbvax.Berkeley.EDU> <957@osf.OSF.ORG>
Reply-To: bob@cmpfen.UUCP (Bob Breum)
Organization: Computer Fenestrations, Lake Monroe, Florida, USA
Lines: 38

In article <957@osf.OSF.ORG> dbrooks@osf.org (David Brooks) writes:
>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.
>
>When I tried using a startup program, (don't remember if it was this
>one) I had the following problem.  The STARTUP program loads itself in
>the bottom of user memory.  Then it loads other resident programs
>above itself.  Then it terminates, leaving a hole where it used to be,
>and GEMDOS can't use that hole.
>
>In other words, STARTUP reduces the memory available on my ST compared
>with using the AUTO-folder ordering.

Wrong.

The version of STARTUP.PRG which I have used for quite a long time now
actually consists of two parts:  STARTUP.PRG and STARTUP.TOS.  The former
runs from your \AUTO folder and loads the latter into high memory.  It is
this latter program which performs the startup processing.  When it
terminates, it leaves no hole in memory, because it was out of the way in
high memory.  It works extremely well.

Murray put a lot of work into this program.  Don't trash it when you don't
know what you are talking about.






-- 
Computer Fenestrations						      Bob Breum
Post Office Box 151		{uiucuxc|hoptoad|petsd|ucf-cs}!peora!cmpfen!bob
Lake Monroe, FL 32747 USA
+1 407 322-3222						   "C is the new BASIC"