Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zephyr.ens.tek.com!gvgpsa!treehouse!andyp From: andyp@treehouse.UUCP (Andy Peterman) Newsgroups: comp.sys.mac.programmer Subject: Re: Standard File and Working directories... Message-ID: <915@treehouse.UUCP> Date: 27 Jun 91 01:10:55 GMT References: <174203@tiger.oxy.edu> Organization: The Treehouse Lines: 60 In article <174203@tiger.oxy.edu> schorsch@oxy.edu (Brent William Schorsch) writes: >OK, about WD's and all this. If you've been following, I originally >posted code requesting how to convert CurDirStore and SFSaveDisk into >a WDDirID; The whole world has come back at me and said, "Ack! Don't >use Working Directories, you'll kill yourself!" > >OK, again. So I didnt want to let the cat out of the bag (no big secret >anyway) but I am writing an entire replacement for Standard File >Routines... Thus I *have* to be able to open a WD to pass back to >calling applications to maintain compatibility (in 7.0 using the >BO~?FSSpecs are great, easy and no problem). > >Ok, again again. So who knows the scoop on using this WD's properly. >Should my extention open them with ProcID of 'ERIK' or my creator? >Should I leave them open (and let the system close them--or will it) >or should I close them at some specific time? (And does that time have >to been when the app I returned a WDDirID to quit in case it stored >the ID and can use it any time it is open?) Any pitfals, suggestions >you know of? Please let me, better yet, us all, know. I've been needing to fix a bug with working directories in my application and your question prompted me into digging into WDs some more (and, I've found the bug in my app after searching for the last year!!!). So now I feel like sharing this sudden burst of knowledge. First of all, check out Tech Note 190 (which tells you to ignore information in TN #77 and TN #126). When opening WDs under MultiFinder, the ProcID you supply is ignored and the current MultiFinder process ID is used instead. When an application quits, MultiFinder scans the WD table and closes off any working directory with that process ID. In other words, SFGetFile doesn't need to worry about closing off WDs. By the way, I checked and SFGetFile uses 'ERIK' for a procID when it creates the WD. This is because if you are not running under MultiFinder, then Finder uses this to close off unused WDs - any WD belonging to another "process" is left open. If you're interested in seeing information on WDs, a pointer to the WD table in memory (WDCBsPtr) is at global location $372. This points to the head of a table whose first two bytes are the size of the table and each of the following 16 bytes is one WD entry. For each entry (one for each working directory), there are four 4 byte fields: the first is a pointer to the volume control block (VCB) for that WD's volume (from which you can get the volume name, refnum, etc), the next field is the directory ID on that volume, the next field is always 0 (??), and the last field is the procID. I'm not sure what the first two working directory entries are, but I think the first one indicates the current "volume" from the last SetVol or HSetVol. Working directorys start with refnum $8023 and continue with $8033, $8043, etc. where the low 12 bits of the wdRefNum are the offset from the start of the table (I don't understand why its $23 bytes - should be $22 bytes). When a WD is closed, the VCB pointer field is zeroed and the first entry with a zeroed field is then used the next time a new WD is opened. I hope this helps. Note that much of this information is undocumented and has been determined by poking around in memory - be careful! -- Andy Peterman | Everything you know treehouse!andyp@gvgpsa.gvg.tek.com | is wrong! (916) 273-4569 | FST