Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!YALE.ARPA!fischer-michael From: fischer-michael@YALE.ARPA (Michael Fischer) Newsgroups: comp.sys.atari.st Subject: Re: ...GEMBOOT... (really usage of shell_p) Message-ID: <8705132037.AA18859@yale-celray.arpa> Date: Wed, 13-May-87 16:37:41 EDT Article-I.D.: yale-cel.8705132037.AA18859 Posted: Wed May 13 16:37:41 1987 Date-Received: Sat, 16-May-87 06:42:11 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Allan Pratt reports: > I have investigated the alleged use of _shell_p by the AES and > the Mark Williams shell, and I can't see that either of them uses this > variable. It's not surprising that none of these programs access location 0x4f6. However, they obviously do use the string that is pointed to by that location. There are probably other pointers to it floating around as well. I think the Mark Williams shell receives this string as its environment string when it is invoked, so it presumably accesses it through its basepage. To find out how the basepage gets set and why, you'll have to look at the DESKTOP and/or the code for Pexec. Perhaps the DESKTOP passes the value of _shell_p to Pexec when you double click on a .PRG file. Or perhaps the desktop supplies a 0 to Pexec, and Pexec simply passes on the DESKTOP's own environment string, which it in turn probably gets from GEMBOOT. Hope this helps. --Mike Fischer Arpanet: UUCP: Bitnet: -------