K538915@CZHRZU1A.BITNET (05/15/87)
Mike Fisher (fisher@yale.arpa) writes >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 ................................. >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 ................... I'm pretty sure that the DESKTOP PExec's with the string pointed to by _shell_p used to make a enviroment string of the form PATH=A:\;...... rsrc_load and shel_find probably use the shel_envrn call to get a pointer to the string following PATH= in the basepage. To try this out, use something like the shell for OSS PERSONAL PASCAL which doesn't try to maintain its own PATH. An example: I've got PATH set to C:\;D:\;E:\;F:\;D:\UTILITIE.S\; this enables me to execute a program in D:\UTILITIE.S\ from the Pascal shell and it will still find the resource file in D:\UTILITIE.S\. Simon Poole K538915@CZHRZU1A.BITNET PS: Allan, I'm Simon not "Simon" (or are you "Allan"?) PPS: Mike, how does it come that we are consulting Atari on their own OS?
K538915@CZHRZU1A.BITNET (05/16/87)
OK, I admit I was probaly wrong, I did some more research into how GEMBOOT
uses _shell_p: it seems that the only reason Konrad Hahn uses it, is so
that SETPATH can be used to change the path, the AES actually uses
$A0A6 to save the pointer to the enviroment string (have a look
at the code pointed to by exec_os ($4FE). One doesn't actually need _shell_p
to set the path at boot-time, so I suppose Konrad could make a version without
using this semi-documented location (maybe one day Atari will decide on
for what it actually is :-)).
Simon Poole
K538915@CZHRZof yto iupsapratt@atari.UUCP (Allan Pratt) (05/19/87)
> [Simon Poole:] > > OK, I admit I was probaly wrong, I did some more research into how GEMBOOT > uses _shell_p: it seems that the only reason Konrad Hahn uses it, is so > that SETPATH can be used to change the path, the AES actually uses > $XXXX to save the pointer to the enviroment string (have a look > at the code pointed to by exec_os ($4FE). One doesn't actually need _shell_p > to set the path at boot-time, so I suppose Konrad could make a version without > using this semi-documented location (maybe one day Atari will decide on > for what it actually is :-)). > > Simon Poole > K538915@CZHRZU1A.BITNET Thank you, Simon. Yes, you were wrong. Whoever posted the note to the effect that the ROMs don't contain the word $04f6 was right. Whoever posted the note to the effect that you can change the string pointed to by $04f6 (thanks to GEMBOOT) was right: the pointer at $04f6 is surely the SAME as some other pointer (e.g. the one used by the Desktop for the environment of its children). Finally, addresses like the one I X'ed out above should not be published, because they change from ROM to ROM (even between countries for a given ROM release). Atari (i.e. Landon) decided long ago what _shell_p was for (see below), just as I said in this group. But even if we hadn't, it is not appropriate for you (or anybody else) to usurp system variables for your own use. If you don't grok the description of a variable, consider it "Reserved for future use BY ATARI" and then yell at us to fix the documentation. Please remove references to _shell_p as a path pointer from your code. It is intended as a pointer to a shell routine for executing command lines. At the end of this article is an example of how we hoped this would work, and how it does work in some shells (notably Gert Poltiek's). ********************* Now for the big news: if you put all your resource files in the root of your boot device (C: for hard disk users) the AES will find them no matter where the .PRG is started from! This is because the environment the AES gets initially includes "PATH=;C:\;" and it looks in this path when you do the shell_find call (which rsrc_load uses). Watch this space for a program which lets you put your resources in any directory! ********************* /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/ *************** CODE EXAMPLE FOR USE OF _shell_p VARIABLE ***************** /* * Example of use of _shell_p variable. * * The value at _shell_p is the address of a procedure which takes a * string pointer as an argument, executes the string as if it were * typed at the shell prompt, and returns the exit status of the command. * * This code checks to see of the value at _shell_p is null (no shell * around) or points to the word "PATH" (adulterated by GEMBOOT). */ #include <osbind.h> main() { long oldstack; long *shell_p = (long *)0x4f6; long (*shell)(); long status; char buf[256]; oldstack = Super(0L); /* get into Super mode */ shell = *shell_p; /* get value of _shell_p */ Super(oldstack); /* get back to user mode */ /* validate _shell_p */ if (shell == 0L) { printf("No shell available to execute a command\n"); Pterm(-1); } if (strncmp(shell,"PATH",4) == 0) { printf("_shell_p has been adulterated: it points to \"PATH\"\n"); Pterm(-1); } /* get a line from the keyboard using Cconrs() */ printf("Enter a command line for the shell to execute: "); buf[0] = 253; Cconrs(buf); buf[2+buf[1]] = '\0'; /* null-terminate the line */ /* execute the command */ status = (*shell)(&buf[2]); printf("Return status is %ld\n",status); Pterm0(); }
K538915@CZHRZU1A.BITNET (05/19/87)
As I just noticed there IS a pointer reserved for the environment string
the_env ($4BC). What I'll do right now is patch my copy of GEMBOOT and
SETPATH to use this location and we can bury this discussion once and for all!
Simon Poole
K538915@CZHRZU1A.BITNETjohn@viper.Lynx.MN.ORG (John Stanley) (05/19/87)
In article <8705182113.AA17190@ucbvax.Berkeley.EDU> K538915@CZHRZU1A.BITNET writes: >As I just noticed there IS a pointer reserved for the environment string >the_env ($4BC). What I'll do right now is patch my copy of GEMBOOT and >SETPATH to use this location and we can bury this discussion once and for all! > > Simon Poole > K538915@CZHRZU1A.BITNET I wouldn't do that Simon... The data at $4bc is suppost to be the default environment string itself, not a pointer. (At least acording to a quick glance I just took in Abacus "Internals"...) Then again... Hold the phone. I just glanced at that location and discovered that the first two bytes are counting.. at approx 200hz... < ??Anybody know what's going on here?? > Ah, got it... The address given in the Abacus book is wrong..! $4BC IS counting at 200hz.. The 200hz clock is a long starting at $4ba. So, it looks like the_env is really at $4BE... not $4bc.. I still don't think it's a pointer... --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
K538915@CZHRZU1A.BITNET.UUCP (05/20/87)
Allan, just for the record:
I have at no time in any form advocated the use of undocumented
system variables on any computer system I have used, nor have I
published any program on any media which uses such variables.
I mentioned location $XXXX only to illustrate why I was wrong and NOT
to induce anybody to actually use it!
Simon Poole
K538915@CZHRZU1A.BITNET
"What about building a hex number filter into rn?"gert@nikhefh.UUCP (05/20/87)
In article <8705182113.AA17190@ucbvax.Berkeley.EDU> K538915@CZHRZU1A.BITNET writes: >As I just noticed there IS a pointer reserved for the environment string >the_env ($4BC). What I'll do right now is patch my copy of GEMBOOT and >SETPATH to use this location and we can bury this discussion once and for all! > > Simon Poole > K538915@CZHRZU1A.BITNET The name at least sounds more like it! Maybe this location is read out by the desktop just after startup. It may very well be another unused location (there's a lot of them). Maybe you should do some digging in the desktop code to see if and how this location is used. I hope that it is used for more than just passing a 'path'. Gert Poletiek.
K538915@CZHRZU1A.BITNET.UUCP (05/20/87)
I write: >As I just noticed there IS a pointer reserved for the environment string >the_env ($4BC). What I'll do right now is patch my copy of GEMBOOT and .......... As John Stanley correctly remarks the location $4BC is WRONG, I accidently was using the old Data Becker ST Intern (Abacus ST Internals) book, the most recent release (If I remember correctly something like mid 1986 (I don't think this version ever made it to the US)) gives the correct value $4BE. The ST internal books does say it IS the default enviroment string (4 nul bytes), but as I was unable to find any reference to it in the system code it is probably safe to use it as a pointer. I've patched my copy of GEMBOOT and SETPATH and they work as normal without any problems. For the undocumented/unpublished system variables freaks: according to the BIOS listing a different location is used by the BIOS as a pointer to the enviroment string, the location is $XXXX (CENSORED BY THE ATARI MAIL FILTER). Simon Poole K538915@CZHRZU1A.BITNET
K538915@CZHRZU1A.BITNET (05/21/87)
Gert Poletiek writes: .... >I hope that it is used for more than just passing a 'path'. ^^^^ Gert, 'just'? Even on such bl**dy systems as IBM-PC's you can set a PATH variable, which most programs actually use. As I've already mentioned there is a VERY simple call to the AES which will return the complete GEMDOS path to a file, if found in the PATH list. If I didn't think this feature was important, I would have never started this fight. Allan Pratt writes: >Now for the big news: if you put all your resource files in the root >of your boot device (C: for hard disk users) the AES will find them >no matter where the .PRG is started from! This is because the environment >the AES gets initially includes "PATH=;C:\;" and it looks in this path >when you do the shell_find call (which rsrc_load uses). Watch this space >for a program which lets you put your resources in any directory! A) This is not big news, I've mentioned the fact a few times that the AES uses 'PATH', as I said before, this is the reason I started the fight in the first place. B) Aha, so ATARI has suddenly decided that we can boot from a harddisk? When are we going to be able to get the boot program from our local dealer? Simon Poole K538915@CZHRZU1A.BITNET
K538915@CZHRZU1A.BITNET (05/21/87)
Allan Pratt writes >....If you don't grok the description of a variable, consider it >"Reserved for future use BY ATARI" and then yell at us to fix the >documentation. Which documentation do you mean? The vaporware documentation which was supposed to be available half a year ago? If you are talking about the dev-pac where do I get updates from (if we had been able to buy it in the first place)? Simon Poole K538915@CZHRZU1A.BITNET PS: take the geographic location of CZHRZU1A (Switzerland) into account!
apratt@atari.UUCP (Allan Pratt) (05/21/87)
> Allan Pratt writes: >>Now for the big news... >>... your boot device (C: for hard disk users) > > B) Aha, so ATARI has suddenly decided that we can boot from a harddisk? > When are we going to be able to get the boot program from our local > dealer? > > Simon Poole > K538915@CZHRZU1A.BITNET Well, there I go again, putting my foot in my mouth. The hard-disk booting code is not available yet. It is ready; its unavailability is a policy decision. If you would like to influence this policy, please send your opinion BY MAIL to Leonard Tramiel / Atari Corp. / 1196 Borregas Ave. / Sunnyvale, CA 94086 / USA. Simon, since you are in Europe, the availability of updates (etc.) is governed not by Atari USA but by another division. I don't know who or where the people handling Switzerland are (Germany? France? Switzerland?), but they are the ones you should complain to about updates. Do you have Alcyon 4.14? That's one of the most important updates you should know about. Other than that, there have been improvements to the standard library modules xmain.o and xopen.o, and a new gemstart.o (and gemstart.s) with a configurable memory model. [This is a plug: these three improvements are by me.] /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/
bammi@cwruecmp.UUCP (Jwahar R. Bammi) (05/29/87)
In article <737@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >> Allan Pratt writes: ....... >Do you have Alcyon 4.14? That's one of the most important updates >you should know about. Other than that, there have been improvements >to the standard library modules xmain.o and xopen.o, and a new gemstart.o >(and gemstart.s) with a configurable memory model. [This is a plug: >these three improvements are by me.] The gemstart.s is certainly a very nice one. As i mentioned before here, xmain.o (the one that was put up in the developers section on CIS) is broken. Someone did leave an example showing how several months ago. No new version has appeared since. Any idea when a fixed version will be available?? -- usenet: {decvax,cbatt,cbosgd,sun}!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155