t68@nikhefh.nikhef.nl (Jos Vermaseren) (11/27/90)
Hi, Can anyone help me with the following? For an application in the new TOS on the TT it would be nice if the application can read some variables from the environment. When an application has been made into an icon on the desktop the file that is dragged on it wants to assume that the current directory is the one it came from. On the other hand the program that lies on the desktop may want to get additional files from its own directory. There is only one current directory -> conflict. The environment would solve this. Hence the question: is there an official legal Atari sanctioned way to add variables to the environment of the desktop? The only way I can come up with is a terrible hack that leaves a little resident job with the new string. It has to look amoung its ancestors for which one is the desktop and then modify its pointer to the environment. If this is the `official' way I would like to know that too, but it is quite thinkable that there are already better ways. After all, the new desktop seems to be somewhat ahead of its documentation (as nearly all programs, except those from ...). Many thanks in advance Jos Vermaseren
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (11/28/90)
t68@nikhefh.nikhef.nl (Jos Vermaseren) writes: >is there an official legal Atari sanctioned way to add variables >to the environment of the desktop? The only way I can come up >with is a terrible hack that leaves a little resident job with >the new string. It has to look amoung its ancestors for which one >is the desktop and then modify its pointer to the environment. >If this is the `official' way I would like to know that too, >but it is quite thinkable that there are already better ways. There seems to be no official way to extend the system environment. You _could_ do it this way: Place some program in your AUTO folder that links into the exec_os vector. Wait for someone to jump thru the vector (that is, wait for AES to come up). In this moment, patch the environment as desired or install a new one. Unfortunately, this method has been discouraged by ATARI systems programmer Allan Pratt at the last ATARI Messe in Duesseldorf. Exec_os seems to be no longer a documented system variable. So if you do this, it's your own problem if it won't work in upcoming TOS versions. This is a pity because exec_os is such an extremely useful system variable, but well... Maybe Mr Pratt has some better (and official) solution for this? ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
sstreep@next.com (Sam Streeper) (11/30/90)
In article <3285@medusa.informatik.uni-erlangen.de> csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes: >t68@nikhefh.nikhef.nl (Jos Vermaseren) writes: > >>is there an official legal Atari sanctioned way to add variables >>to the environment of the desktop? The only way I can come up >>with is a terrible hack that leaves a little resident job with >>the new string. It has to look amoung its ancestors for which one >>is the desktop and then modify its pointer to the environment. >>If this is the `official' way I would like to know that too, >>but it is quite thinkable that there are already better ways. This way works very well. I use this method so that my environment from the desktop matches my environment when I am running from within the Laser shell. The overhead is insignificant - a 256 byte basepage plus about 50 bytes of assembly language code plus the length of the new environment strings. If anyone wants I can post the example. (This code is not original; I modified it from code posted to the net about 4 years ago. If I recall correctly it doesn't use any questionable kludges...) >There seems to be no official way to extend the system environment. >You _could_ do it this way: Place some program in your AUTO folder >that links into the exec_os vector. Wait for someone to jump thru >the vector (that is, wait for AES to come up). In this moment, >patch the environment as desired or install a new one. Ack! don't do that! (I know, atari programming sometimes makes you jump through hoops. Does it bother anyone else that Gem periodically resets the trap #2 vector? Like "you didn't reset that for a reason, did you? Here, let me fix it!") -sam (sam_s@NeXT.com)