Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!amdahl!nsc!voder!apple!lsr From: lsr@apple.UUCP (Larry Rosenstein) Newsgroups: comp.sys.mac Subject: Re: HFS Questions Message-ID: <1593@apple.UUCP> Date: Mon, 24-Aug-87 14:17:42 EDT Article-I.D.: apple.1593 Posted: Mon Aug 24 14:17:42 1987 Date-Received: Tue, 25-Aug-87 06:40:14 EDT References: <1071@vu-vlsi.UUCP> <1560@apple.UUCP> <6923@dartvax.UUCP> Reply-To: lsr@apple.UUCP (Larry Rosenstein) Distribution: na Organization: Advanced Technology Group, Apple Computer Lines: 95 Keywords: HFS, Launching Applications In article <6923@dartvax.UUCP> earleh@dartvax.UUCP (Earle R. Horton) writes: > >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: Standard File maintains its own idea of the first folder to show when the dialog is displayed. This is documented (for HFS) in Inside Mac volume 4. There are 2 global variables that contain the (true) volume refnum and dirID of the folder that Std File will show first. I did an experiment with Finder 5.5 and System 4.1, and found that that when you open a document the Finder sets these variables itself to establish the folder that Std File will use initially. What I did was to double click on a MacWrite document the root of an HFS volume, with MacWrite in a folder on the same volume. I used Macsbug's SS command to break whenever location $398 (one of the Std File variables) changed. The variable changed twice during the launch. I think that the first time it was set to the folder containing MacWrite and the second time to the folder containing the document. I also checked to see if a call to PBHSetVol changed the Std File variables, and it did not. >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". When you boot, the Std File variables are not set. The first time you bring up Std File, it notices this and defaults to the root of a volume (probably the current volume). When you launched the application you used Std File, which set the variables. When you brought up Std File again, it used the same variables and showed the same directory. You can't tell what the current volume is by looking at the folder that Std File shows you. The 2 things are completely different. ExitToShell does set the current folder to the one containing the Finder. (Look at locations $40F6EC-$40F6F2 of the Mac Plus ROM; this is a call to SetVol using BootDrive as the parameter.) >Now, for the most interesting part, the undocumented feature of Launch! >I claim that you can launch an application by: >...[using full pathnames] > Absolutely true. Full or partial pathnames are valid in the file system calls. The Launch code makes standard file system calls, so full pathnames are valid there as well. The Launch code does not change the current volume, this is done by the Finder. >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. I wouldn't recommend this either. You should always launch applications by setting the current volume, because some applications depend on this. Any shell-type application that does not set the current volume before a launch is wrong. >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? I still argue that you should use the current volume in effect when the application is launched. Although there is nothing inherent in the Macintosh that makes this so, there is a very strong convention that makes this so. (The Finder and MPW Shell both do this, and some applications depend on this fact.) If you do not want to use this technique, I think you could call PBGetFCBInfo (see Inside Mac volume 4) and pass it the application's refnum (available from a global variable). I haven't tried this, but I think it should work based on what is written in Inside Mac. This call is NOT in the 64K ROMs, however, and the documentation says that the format of the file control blocks may change in the future. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com