Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ucbvax!DBNUAMA1.BITNET!VBRANDT
From: VBRANDT@DBNUAMA1.BITNET
Newsgroups: comp.sys.atari.st
Subject: Line F again
Message-ID: <8912200800.AA14560@ucbvax.Berkeley.EDU>
Date: 20 Dec 89 08:01:36 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 68
X-Unparsable-Date: Tue, 19 Dec 89 11:32:18 SET

Hello all,

[I'm sorry that I reply only now to this message, but the recent amount of
 Info-Atari16 Digests gave me a hard time catching up.]

In Info-Atari16 #705, John M Williams (jmw%tasis.utas.oz@uunet.uu.net) said
in reference to my earlier posting:

>A recent article suggested three possible methods by which a process  could
>determine whether it was being run from the desktop or from a shell. I'd like
>to suggest another method which works for me. I don't suggest that it is
>foolproof however. It simply requires moving the basepage ptr up to its parent
>until it becomes null. If this requires three iterations then the program
>is running from the desktop. Any more and it is running from a shell.
[Code example omitted]

In Digest #734, nis!pwcs!stag!daemon@UMN-CS.CS.UMN.EDU (Dale Schumacher)
replies:

>Alright, I guess it's time to post this message again (is this the 3rd
>time now?).  The quoted message is mostly correct, but incomplete.  The
>situation is slightly different if you're in the /AUTO/ folder programs
>at boot-time.  I check for the text-base pointer pointing to ROM, as
>recommended by Allan Pratt @ Atari.  The following code (which, like John's
>code, assumes access to a basepage pointer) uses this "approved" method.
>I've also included a copy of <basepage.h> from dLibs for those who don't
>know the layout of the basepage structure.
[Code example omitted]

Finally, in Digest #740, portal!atari!apratt@uunet.uu.net (Allan Pratt) joins
the discussion:

>dal@syntel.mn.org (Dale Schumacher) writes:
>>I check for the text-base pointer pointing to ROM, as
>>recommended by Allan Pratt @ Atari.
>
>Yeah, well, that was before there were RAM TOSes running around. Caveat
>hacker.  No RAM TOS is supported by Atari (at this time) and most are
>illegal copies, making their users pirates, so it's not that great a
>hardship.

  Thank you all for replying.  One of the things I wanted to find out by posting
my original code samples was whether one can rely on the 'somewhat-documented'
facts one has to exploit to find out where the process came from.

   Is the three-times-iteration method approved?  Will it hold true in later
TOS revisions?  Same goes for my method, checking the os_magic pointer.  I took
pains to ensure that the code samples I sent out also work with TOS 1.6 (STE)
and TOS 3.0 (TT).  Dales version has the advantage of also detecting that the
program was started from the auto folder.  My version also works with RAM and
STE/TT TOSes.

   Maybe Allan can tell us if one or the other method will be supported by
Atari, or if there will be some kind of system variable that tells the current
process if his parent is a shell or the desktop.  Such a variable would also
make life easier for programs like Neodesk etc.

   A side note to Allan:  Take the ROM TOS 1.4, disassemble it, make it fully
relocatable, write a little RAM loader, and you have a RAM TOS.  Does that make
me a pirate???   [BTW: Such a RAM TOS is great for testing out little OS tweaks
and patches ... :-)]


----------------------------------------------------------------------------
Bitnet:  VBRANDT@DBNUAMA1 (will go away some day ...)  Volker A. Brandt
          UNM409@DBNRHRZ1 (alternative)                Angewandte Mathematik
UUCP:    ...!unido!DBNUAMA1.bitnet!vbrandt             (Bonn, West Germany)
ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU