Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!decwrl!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: TOS bugs. Disk related.
Message-ID: <1435@atari.UUCP>
Date: 5 Apr 89 21:23:58 GMT
References: <763@stag.UUCP> <1426@atari.UUCP> <460@electro.UUCP>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 63

In article <460@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
> when you install an application on the desktop (you know, click on a program,
> go to the menu entry for install application, type in the extender for the
> program and click install), and then click on a file with the correct 
> extender for that application, the desktop seems to stick in a carraige 
> return into the commandline for that application.
> 
> ie: the commandline buffer in the base page will contain the length byte,
> the the filename clicked on, and then a carraige return before the null
> termination byte. the carraige return does not appear when you run the 
> program from the numerous commandline shells in existence.

The command line is not null terminated.  The nulls just happen to be there.
The only correct assumption to make is that the command line length byte
tells how many valid characters there are in the command line.  You will
notice that an argument like "foo" will give a command line length byte
of three, and the CR is the fourth byte in the command line space.

Note that this convention is violated by MWC: they put $7f in the command
line length byte (and null-terminate the real command line) to indicate
that ARGV is in the environment.  See the discussion going on in this
newsgroup for more on that.

> also, say you were in a couple of subdirectories deep on a drive, and click
> on a file with the correct extender for that application. what seems to 
> happen now is that the desktop will do a pexec load call to load the program
> into memory, change directory back to the directory containing the file you
> clicked on, and do a pexec go call. is this a correct assumption??
> (this is based upon the fact that only the filename appears in the commandline
> in the basepage, NOT the complete path to the filename!!) if it is true,
> will this mannerism change in the future?? it is a nice feature if it is true!

Your reverse-engineering of what goes on is admirable for its
complexity.  The truth is that you can call Pexec (or any other GEMDOS
function) with a full-blown pathname to the file in question, so no
changing of directories is required.  What you see on the screen or in
your command line and what got passed to GEMDOS can easily be two
different things. 

Your current directory when the program starts is the directory where
the file was double-clicked.  The argument you find on your command line
is the name of the file which was double-clicked, with no path or drive
information.  This has always been true, and it is still true. 

If you use the right button to double-click a document from a window
which is not the top window (did you know you could do this?), I don't
know what happens in original TOS or Mega TOS, but TOS 1.4 "tops" that
window before starting the installed application, making that the
current directory.  This is for clicking documents for installed
applications only: if you use the right button to double-click an
application outright, the current directory is still the top window.

TOS 1.4 has a new feature in this area: shell_find (which rsrc_load uses
to find resource files) now looks in more places, including the place
where the application was loaded from, even if that's not the current
directory.  Therefore an "installed" application will find its resource
file no matter where it lives, as long as the resource file and the
application are in the same place.  There are more details in this
area; see the TOS 1.4 release notes for full details.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt