Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!sdcrdcf!trwrb!cadovax!gryphon!crash!pnet01!fred
From: fred@pnet01.cts.com (Fred Brooks)
Newsgroups: comp.sys.atari.st
Subject: Re: preloading programs (shell)
Message-ID: <2920@crash.cts.com>
Date: 5 May 88 00:16:10 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 57

>Never used gemdos call 0x4b (Exec) with a mode of 4?
>You can have preloaded programs on the Atari ST as well, and it works quite
>nicely. I used it in a find command and in a shell I programmed for the Atari 
>(yes, the Unix find command!), for example:
>find .. -type d ! -name . ! -name .. -exec ls -l {} \;
>(For those not familiar with find, this one finds all directories beneath 
>the current directory's parent (excluding . and .. names) and does a ls -l
>on each one of them).
>
>Each time loading ls worked fine on the ramdisk I used to use, but once I
>started working on a hard disk, it becomes really slooooooooooowwww!
>Then I decided to preload the ls command (with gemdos(0x4b,3,"ls",0,0)).
>The gemdos function returns the basepage address of the loaded program.
>Now 'find', each time it has to 'ls', copies the argument string into the
>basepage; then it runs 'ls' by gemdos(0x4b,4,0,0,0) (I don't remember whether
>these are the correct values for the parameters). It is now (nearly) as fast 
>as a builtin function!
>
>There are however a few problems (and I have not solved all of them):
>1) When the parent program changes directories, the child stays in the directory
>it started in (the current directory and disk are saved somewhere on the 
>basepage, start+55?).
>2) There is also a problem with the memory; the loaded child obtains, as usual
>the rest of the memory available (in addresses basepage+4 to basepage+7 the
>address of the 'next free location' or something like that is found: 0xF8000 on
>my 520 ST+). Thus there is a problem with multiple preloaded childs or childs
>requesting additional memory. I've overcome this (sort of) by using setblock
>(gemdos 0x4a) and adjusting the 'next_free_location' ptrs on the childs 
>basepages. It's better now, but still buggy (I don't know all about Gemdos
>memory management, I'm finding out now).
>3) There could be problems as well with file descriptors (they're also on the
>basepage).
>4) Initialized static and extern variables do not regain their initial value
>after a run. This is in consequence of the 'once-only' load. It could be
>overcome by a) always explicit initializing (by the child process), or 
>b) make a copy of the initialized data space (by the parent process) and use 
>this to re-initiate from the next time (more expensive, but not breaking 
>existing code).
>
>If you manage to overcome these difficulties, it should not be very hard to
>code this preloading into a shell (I did it, having still these little problems
>...). The shell maintains a list of preloaded programs, their pathname and
>their fat number and handles loading/executing depending on memory available,
>programs preloaded etc. Preloaded programs are almost as fast as functions
>built into the shell.
>
>If anybody has suggestions about the memory management part, or questions 
>'about the real code', or want examples, please RESPOND! A commented disassembly
>of the gemdos part of the O.S. would also be great ....
>
>		leo.

Is your shell PD or can you post it. I'm looking for a complete unix bourne
or korn shell source so i can add the multitasking part with my MX2 kernel.

UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!fred
ARPA: crash!pnet01!fred@nosc.mil
INET: fred@pnet01.cts.com