Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!decvax!dartvax!earleh
From: earleh@dartvax.UUCP (Earle R. Horton)
Newsgroups: comp.sys.mac
Subject: Re: HFS Questions
Message-ID: <6923@dartvax.UUCP>
Date: Sat, 22-Aug-87 19:16:20 EDT
Article-I.D.: dartvax.6923
Posted: Sat Aug 22 19:16:20 1987
Date-Received: Sun, 23-Aug-87 22:14:30 EDT
References: <1071@vu-vlsi.UUCP> <1560@apple.UUCP>
Distribution: na
Organization: disorganized
Lines: 72
Keywords: HFS, Launching Applications
Summary: Launch, undocumented feature?

In article <1560@apple.UUCP>, lsr@apple.UUCP (Larry Rosenstein) writes:
> 
> The current volume (as returned by GetVol) will indicate the folder
> containing the application.  This will be a wdRefnum if the application is
> inside a folder.
...
> Launch uses the current volume.  The code for ExitToShell does a SetVol
> back to BootDrive before launching the Finder.
>
I believe there are problems with both of these statements.  I base this 
claim on the assumption that SFGetFile will always show files in the default
volume, and from observation of what folder I get from SFGetFile.  If this
assumption is false, then I may be wrong.  I am using the term "volume"
here to mean directory or folder, which appears to be the way Larry meant
it.  Sloppy, but you probably know what I mean.

I have noticed that when you launch an application by double-clicking
one of its documents, then do anything that uses Standard File, you
usually get the folder the document is in, and not the folder the
application is in.  This indicates to me that either:

     a)  All Mac applications use SetVol before opening documents
         (unlikely since not necessary)
     or
     b)  The default volume gets changed to the one the document(s)
         were in when using the double-click-document method
     or
     c)  The Standard File package maintains its own default volume
         (unlikely)

I wrote an application which calls SFGetFile to find an application,
then launches it.  Named it "Finder" and put it in the system folder,
booted from the disk.  The folder shown first by SFGetFile is the root
folder, and not the system folder.  OK so far.  However, when I launch
an application on another volume (disk) and later quit back to my phony
Finder, I get the folder containing the application that I launched, and
not the one my bogus Finder is in.  In this case, ExitToShell appears
not to change the default volume or directory when launching the "Finder".

Now, for the most interesting part, the undocumented feature of Launch!
I claim that you can launch an application by:

     a) Calling SetVol to set the default volume to a directory the
        target application is NOT in, and on a different volume (disk).
     b) Calling Launch with a pathname that specifies the application
        you want.

I also claim that the default volume remains the volume set in the first
call to SetVol, before the launch.  (This is with System 4.1, Finder 5.5.,
ROM version 117.)

I have example code which demonstrates this, if anyone is interested.
It's a program called RMaker.  (I have a demo I wrote myself, too.)

I don't recommend launching applications using pathnames, or even using
any undocumented features, but it does appear to me that one cannot
always depend on GetVol returning the same folder or WDRefNum that your
application is in.  It also appears that ExitToShell does not always
set the default volume to the one the Finder is in, either.

Please let me know if I am wrong.  If I am, what makes SFGetFile look
in what appears to be the wrong directory?  (I know the Launch trick
works, however, and I would not be surprised to find out that a large
number of "batch" type programs use it.)

In any case, the root question remains unsolved.  Does anyone have code
which will return, guaranteed, the WDRefNum of the folder which the 
current application is in?
-- 
*********************************************************************
*Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755   *
*********************************************************************