tnzoerne@faui09.informatik.uni-erlangen.de (Thorsten Zoerner) (05/29/91)
Question on Environment: I am actually writing a program, that shall read some Variables out of the environment. But I reckognized something very strange: Desktop overgives the first called program the environment: PATH=\0 (\0 means Nul-Char) C:\\\0 (\\ means Backslash) \0\0 trash... Now I can't guess, what that second String could mean. It is *not* dependent on the starting-directory. Maybe it shall be the Boot- Directory ? But I load AUTO-Prgs. and DESKTOP.INF from Disk A: !! That is also not the MS-DOS-Standard, as there after the twice-Nul- Bytes the starting-directory should be overgiven, and before only correct Definitions (including a '='). Question on Accessories under Dektop: Is there any way to reckognize from out of an Accessory if the aktual process is the Desktop (when receiving an acc_open) ? I want to write a program, that opens automatically a window on the Desktop to display some things; but that shall not happen in other programs. (Thats no problem in TOS-programs, cause you don't happen to get an acc_open) Perhaps some kind person has an idea and tells me about it ? Thanks, little TOM ---- Thorsten Zoerner, Neuweiherstr.36, D-8523 BD tnzoerne@faui09.informatik.uni-erlangen.de
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (05/29/91)
tnzoerne@faui09.informatik.uni-erlangen.de (Thorsten Zoerner) writes: >PATH=\0 (\0 means Nul-Char) >C:\\\0 (\\ means Backslash) >\0\0 >trash... Normal behavior. Ignore the \0 after PATH, this is really _one_ environment string. >Is there any way to reckognize from out of an Accessory if the >aktual process is the Desktop (when receiving an acc_open) ? No legal way, unfortunately. (Correct me if I'm wrong.) ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus_Brod@wue.maus.de ----------------------------------------------------------------------
neil@cs.hw.ac.uk (Neil Forsyth) (05/30/91)
In article <1991May29.154140.5510@informatik.uni-erlangen.de> csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >tnzoerne@faui09.informatik.uni-erlangen.de (Thorsten Zoerner) writes: >>Is there any way to reckognize from out of an Accessory if the >>aktual process is the Desktop (when receiving an acc_open) ? > >No legal way, unfortunately. (Correct me if I'm wrong.) OK :-) BTW: Atari UK say this is 'OK' to talk about. When an accessory is starting up it should get the address of the OS header at $4F2. This usually points to the start of the ROM, wherever it is, but AHDI might change it. Either way what it points to is, or should be, consistant. At $28 offset from the start of the structure $4f2 points to is a pointer to the process ID of the current process. This is actually its basepage. For an accessory that is starting up this will be the PID of the GEM Desktop since accessories are not processes in the true sense, ie. they belong to the AES and Desktop. The accessory can save this PID and compare it to the current value when the accessory is activated from the menu. If it's the same then we are on the desktop. If not then we are in a program. Actually this is quite handy for adding modules to an existing program. Caveat: This PID pointer does not exist in TOS 1.0. For that ROM version its value is 0x602C execpt for the Spanish ROM where it is at 0x873C. The TOS version is found at offset $2 from the start of the OS header and the country is encoded at offset $1C but the lowest bit is screen freq. eg. ; long *get_pid() ; Return PID pointer for any ROM version. ; (Note: Call this in Super mode for access to _sysbase) SPA: EQU 4 ; Spain country code _sysbase: EQU $4F2 _get_pid:: MOVE.L _sysbase,A0 ; A0 -> OS header CMP.W #$0100,2(A0) ; Is this the old TOS? BEQ.S .old MOVE.L $28(A0),D0 ; D0 = PID address in modern ROMs BRA.S .done .old: MOVE.W $1C(A0),D0 ; D0 = Country and screen freq. LSR.W #1,D0 ; D0 = Country code CMP.W #SPA,D0 ; Is it Spain? BNE.S .other MOVE.L #$873C,D0 ; D0 = Spanish PID BRA.S .done .other: MOVE.L #$602C,D0 ; D0 = Rest of the world PID .done: RTS ; return(D0); END Note the complete lack of XBRA usage in the above example! :-) +----------------------------------------------------------------------------+ ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own ! ! ! ! "I think all right thinking people in this country are sick and tired of ! ! being told that ordinary decent people are fed up in this country with ! ! being sick and tired. I'm certainly not and I'm sick and tired of being ! ! told that I am!" - Monty Python ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK ! +----------------------------------------------------------------------------+
bammi@acae127.cadence.com (Jwahar R. Bammi) (06/04/91)
In article <3101@odin.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes: > BTW: Atari UK say this is 'OK' to talk about. > ...... > At $28 offset from the start of the structure $4f2 points to is a pointer to > the process ID of the current process. This is actually its basepage. > but atariUSA says that this is an "undocumented" variable and you cannot rely on it to exist in the future. i too want it for gdb and agree it is very useful. apratt?? -- -- bang: uunet!cadence!bammi jwahar r. bammi domain: bammi@cadence.com GEnie: J.Bammi CIS: 71515,155
neil@cs.hw.ac.uk (Neil Forsyth) (06/05/91)
In article <BAMMI.91Jun4135526@acae127.cadence.com> bammi@acae127.cadence.com (Jwahar R. Bammi) writes: >In article <3101@odin.cs.hw.ac.uk> neil@cs.hw.ac.uk (I, Neil Forsyth) wrote: >> BTW: Atari UK say this is 'OK' to talk about. >> ...... >> At $28 offset from the start of the structure $4f2 points to is a pointer to >> the process ID of the current process. This is actually its basepage. > >but atariUSA says that this is an "undocumented" variable and you >cannot rely on it to exist in the future. i too want it for gdb and >agree it is very useful. The Rainbow TOS release notes say:- "Here is the procedure which will return the address of the variable _run (what I described) no matter what ROM you have ..." So Atari US are being rather inconsistant here. I think Atari might mean that it should only be used as a process ID and the fact that it is the basepage pointer should not be relied on. >apratt?? APRATT?? >bang: uunet!cadence!bammi jwahar r. bammi >domain: bammi@cadence.com >GEnie: J.Bammi >CIS: 71515,155 +----------------------------------------------------------------------------+ ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK "That was never 5 TOS release notes!" ! +----------------------------------------------------------------------------+