Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!hao!gatech!seismo!mcvax!nikhefh!t68
From: t68@nikhefh.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: correct use of _shell_p....
Message-ID: <281@nikhefh.UUCP>
Date: Wed, 20-May-87 06:52:51 EDT
Article-I.D.: nikhefh.281
Posted: Wed May 20 06:52:51 1987
Date-Received: Thu, 21-May-87 07:14:36 EDT
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 28
Keywords: _shell_p



There is a little to be added to the proper use of _shell_p.
I ran into this problem when building an editor that can also
be run as a desk accessory, and doesn't need to run under a shell.
In that case it has to test whether _shell_p is useable, and if not
it should try to interprete the command itself, just being less powerful.

The problem is that apon a warm reset the value of _shell_p is not restored
to zero, so any program that runs afterwards, but not from the shell will
think that the shell is there and kaboum.....  There is no real solution
to this problem, only a semi solution. The job looks for _shell_p at
startup and it tests its validity, assuming that any shell program will lie
in a lower piece of memory, so the value of _shell_p must be less than the 
basepage address of the utility that uses it. This is not foolproof but
you got to work at it to cheat it ( from the mt shell its not difficult ).
After this it doesn't check the validity anymore.
To have _shell_p point at a 'rts' instruction after booting is not a good
idea, because then there is no safe way of telling whether your command has
been executed, except for putting 'magics' in d0 and looking whether they
got changed. That doesn't work too well from a higher language.

There are more variables that are not reset at a warm boot. Some are most
annoying, like the drivemap. For RAM disks like K-RAM that look for the first
available drive this means that they move up one drive after each reset.

Jos Vermaseren
t68@nikhefh.uucp