schorsch@oxy.edu (Brent William Schorsch) (06/22/91)
If you have severe allergies to the File Manager skip this posting... Glad to see a few die hards still reading this! Anyway, I have some questions regarding WD's. I have used the File Manager fairly often, yet still get confused every now and then... What I need to do is to take the Global Variables SFSaveDisk and CurDirStore and turn them into a WDDirID (the same thing that Standard File would return). I dont need explicit code, just the File Manager Routines needed for the conversion and a simple set of instructions. The next thing, is once I get a WDDirID, can I just use it as though SFGetFile returned it to me, or will the working directory need to be opened before I cal SetVol(0, theWDDirID)? Or anything else? If this is the case how does Standard File do it (that is return the ID of an OPEN WD without the guarantee that it will later be able to close it?) Any light you can shed on this is more that just appreciated, it is saving me money I would otherwise have to pay my analyst after hours of frustration from dealing with the File Manager... Thanks. Ando Moon.
schorsch@oxy.edu (Brent William Schorsch) (06/24/91)
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. Thanks. Ando Ok, last Ok. Ok? (Or is double Caps--OK--Apple?)
dorner@pequod.cso.uiuc.edu (Steve Dorner) (06/24/91)
In article <174023@tiger.oxy.edu> schorsch@oxy.edu (Brent William Schorsch) writes: >What I need to do is to take the Global Variables SFSaveDisk and >CurDirStore and turn them into a WDDirID (the same thing that Standard >File would return). PBOpenWD. >The next thing, is once I get a WDDirID, can I just use it as though >SFGetFile returned it to me, or will the working directory need to >be opened before I cal SetVol(0, theWDDirID)? Or anything else? Just use it. Better yet, don't use it; the only time to use a WD is if you are calling something (to which you don't have source) that requires a WD. A volume reference number and directory id pair are a far better choice; you don't have to worry about closing them, or the system running out of them if you fail to close them. >If this is the case how does Standard File do it (that is return the ID >of an OPEN WD without the guarantee that it will later be able to close it?) All WD's are open. Standard File is getting help from the system when your program exits, I believe. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
keith@Apple.COM (Keith Rollin) (06/25/91)
In article <174023@tiger.oxy.edu> schorsch@oxy.edu (Brent William Schorsch) writes: >If you have severe allergies to the File Manager skip this posting... > >Glad to see a few die hards still reading this! Anyway, I have some >questions regarding WD's. I have used the File Manager fairly often, >yet still get confused every now and then... > >What I need to do is to take the Global Variables SFSaveDisk and >CurDirStore and turn them into a WDDirID (the same thing that Standard >File would return). You don't want to do this. Rather than taking SFSaveDisk and CurDirStore and turning them into a WD, you want to turn the logic around. Take the WD that is given you by standard file and decompose it to its corresponding dirID and vRefNum. This is done with a simple call to PBGetWDInfo (or just GetWDInfo). The reason why you don't want to create WD's is because the table that maps WD's into their dirID/vRefnum pairs is a fixed size table. If you fill it up, your system crashes. And the table tends to get full because there is no good way to determine which entries can be removed. The system takes care of WD's created by standard file, but any that you create are harder to handle. By eschewing WD's, you avoid these problems. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
chuck@brain.UUCP (Chuck Shotton) (06/25/91)
In article <54282@apple.Apple.COM>, keith@Apple.COM (Keith Rollin) writes: > You don't want to do this. Rather than taking SFSaveDisk and > CurDirStore and turning them into a WD, you want to turn the logic > around. Take the WD that is given you by standard file and decompose it > to its corresponding dirID and vRefNum. This is done with a simple call > to PBGetWDInfo (or just GetWDInfo). > > The reason why you don't want to create WD's is because the table that > maps WD's into their dirID/vRefnum pairs is a fixed size table. If you > fill it up, your system crashes. And the table tends to get full > because there is no good way to determine which entries can be > removed. The system takes care of WD's created by standard file, but > any that you create are harder to handle. By eschewing WD's, you avoid > these problems. > Given the raft of Tech Notes on the subject, and the general noise concerning them, I get the impression that Working Directories have fallen from grace. Do they serve a purpose anymore? Why would I ever use one? (This IS a serious question.) Whose idea were they anyway? (NOT a serious question.) ----------------------------------------------------------------------- Chuck Shotton Internet: cshotton@girch1.med.uth.tmc.edu BIAP Systems UUCP: ...!buster!brain!chuck "Your silly quote here." AppleLink: D1683 MacNet: shotton
jcav@quads.uchicago.edu (john cavallino) (06/26/91)
In article <D2150025.iyoxve@brain.UUCP> chuck@brain.uucp writes: >Given the raft of Tech Notes on the subject, and the general noise concerning >them, I get the impression that Working Directories have fallen from grace. >Do they serve a purpose anymore? Why would I ever use one? (This IS a serious >question.) Whose idea were they anyway? (NOT a serious question.) Working Directories are an MFS-compatibility device. They are there so that programs that used the MFS Standard File would still run correctly. Under MFS, a volume refNum and a filename uniquely specified a given file. Under HFS, you need a directory ID in addition. Standard File creates and returns a working directory refNum in place of the volume refNum if the user chose a file in a folder, thus allowing programs that don't know about directory IDs to successfully open the file. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ c+ g+ k s+(+) e+ h- pv (qv) | Telephone: 312-702-6900
andyp@treehouse.UUCP (Andy Peterman) (06/26/91)
In article <D2150025.iyoxve@brain.UUCP> chuck@brain.uucp writes: >Given the raft of Tech Notes on the subject, and the general noise concerning >them, I get the impression that Working Directories have fallen from grace. >Do they serve a purpose anymore? Why would I ever use one? (This IS a serious >question.) Whose idea were they anyway? (NOT a serious question.) I had a long conversation with DTS a few months ago and they are trying to get people to stop using working directories. They say that they may not be supported in the future. As of now, the only place you need to create a working directory is when you launch a new application. In most other cases, you can usually get by with a volume reference number and directory id. Working directories were created when the HFS file system was created as a way to keep older applications compatible. Before HFS, all an application needed to know to locate a file is a volume reference number. SFGetFile would then return either a volRefNum or a working directory refNum and the application wouldn't know the difference. You'll notice under 7.0, you now can get an FSSpec record back from the new StandardGetFile and in other places, such as the Resource Manager's FSOpenResFile or HOpenResFile, you must use the vRefNum and dirID. As soon as everyone stops using 6.0.x (I'm not holding my breath), working directories should disappear. -- Andy Peterman | Everything you know treehouse!andyp@gvgpsa.gvg.tek.com | is wrong! (916) 273-4569 | FST
llama@eleazar.dartmouth.edu (Joe Francis) (06/26/91)
chuck@brain.UUCP (Chuck Shotton) writes: >Given the raft of Tech Notes on the subject, and the general noise concerning >them, I get the impression that Working Directories have fallen from grace. >Do they serve a purpose anymore? Why would I ever use one? (This IS a serious >question.) In answer to why would you ever use one... Before there were the new high level file manager calls (doc'd in a tech note, then put in IM VI), the only way I know of to take a Volume Name, Dir ID, and File Name and manage to open that file is to open a working directory. I would LOVE to be proven wrong on this, so please post any alternatives (given the above assumptions). They high level HFS call HOpen, (TN 218, IM VI) takes a Dir ID directly. The tech note indicates that the call is provided in glue for MPW 3.0+, so presumeably it will work with any HFS system. What I want to know is: does this call result in working directories being opened behind the scenes? If so, are they disposed of properly? ---------------------------------------------------------------------------- "Read My Lips: No Nude Texans!" - George Bush clearing up a misunderstanding
eastman@csa2.lbl.gov (JACK EASTMAN) (06/27/91)
In article <1991Jun26.084825.9019@dartvax.dartmouth.edu>, llama@eleazar.dartmouth.edu (Joe Francis) writes... >chuck@brain.UUCP (Chuck Shotton) writes: > >>Given the raft of Tech Notes on the subject, and the general noise concerning >>them, I get the impression that Working Directories have fallen from grace. >>Do they serve a purpose anymore? Why would I ever use one? (This IS a serious >>question.) > >In answer to why would you ever use one... > >Before there were the new high level file manager calls (doc'd in a tech >note, then put in IM VI), the only way I know of to take a Volume Name, >Dir ID, and File Name and manage to open that file is to open a working >directory. I would LOVE to be proven wrong on this, so please post any >alternatives (given the above assumptions). > Let us also not forget tech note #140, "Why PBHSetVol is Dangerous", wherein we learn that using _HSetVol to change the default directory is a no-no. If you want to change the default directory to a given vRefNum+dirID, and you want to be compatible with all post-HFS systems, you have to compose a working directory and pass it to PBSetVol instead. I presume the bad behavior has been fixed in some more recent version of the System, but I haven't seen a revised TN 140 that tells me so. Am I wrong? Jack Eastman Berkeley Systems, Inc. eastman@lbl.gov
jcav@quads.uchicago.edu (john cavallino) (06/27/91)
In article <1991Jun26.084825.9019@dartvax.dartmouth.edu> llama@eleazar.dartmouth.edu (Joe Francis) writes: >Before there were the new high level file manager calls (doc'd in a tech >note, then put in IM VI), the only way I know of to take a Volume Name, >Dir ID, and File Name and manage to open that file is to open a working >directory. I would LOVE to be proven wrong on this, so please post any >alternatives (given the above assumptions). Your assumptions are screwed up. >They high level HFS call HOpen, (TN 218, IM VI) takes a Dir ID directly. >The tech note indicates that the call is provided in glue for MPW 3.0+, >so presumeably it will work with any HFS system. The "new" high-level calls are just that; new glue for calling existing low-level HFS routines, which are all documented in IM IV, along with the rest of HFS. _HOpen calls _PBHOpen, etc, etc. >What I want to know is: does this call result in working directories >being opened behind the scenes? If so, are they disposed of properly? No working directories involved. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ c+ g+ k s+(+) e+ h- pv (qv) | Telephone: 312-702-6900
andyp@treehouse.UUCP (Andy Peterman) (06/27/91)
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
keith@Apple.COM (Keith Rollin) (06/27/91)
In article <1991Jun26.084825.9019@dartvax.dartmouth.edu> llama@eleazar.dartmouth.edu (Joe Francis) writes: >chuck@brain.UUCP (Chuck Shotton) writes: > >>Given the raft of Tech Notes on the subject, and the general noise concerning >>them, I get the impression that Working Directories have fallen from grace. >>Do they serve a purpose anymore? Why would I ever use one? (This IS a serious >>question.) > >In answer to why would you ever use one... > >Before there were the new high level file manager calls (doc'd in a tech >note, then put in IM VI), the only way I know of to take a Volume Name, >Dir ID, and File Name and manage to open that file is to open a working >directory. I would LOVE to be proven wrong on this, so please post any >alternatives (given the above assumptions). You could open a file with PBHOpen. QED. Some people don't like using the low-level calls, but once you start using them, you find that they aren't that bad. I often prefer using them over the high level calls. >They high level HFS call HOpen, (TN 218, IM VI) takes a Dir ID directly. >The tech note indicates that the call is provided in glue for MPW 3.0+, >so presumeably it will work with any HFS system. > >What I want to know is: does this call result in working directories >being opened behind the scenes? If so, are they disposed of properly? No, they don't create working directories. There are only two reasons for creating working directories: - If you are launching another application that expects to find its location by making a GetVol call. - If you are writing a hack that involves part of the system that still uses working directories. For example, one person was patching StdFile and needed to create WD's. Another person wanted to fake out INIT 31 and needed to create WD's. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
shores@fergvax.unl.edu (Shores) (06/27/91)
In <14699@dog.ee.lbl.gov> eastman@csa2.lbl.gov (JACK EASTMAN) writes: >Let us also not forget tech note #140, "Why PBHSetVol is Dangerous", wherein >we learn that using _HSetVol to change the default directory is a no-no. If >you want to change the default directory to a given vRefNum+dirID, and you >want to be compatible with all post-HFS systems, you have to compose a working >directory and pass it to PBSetVol instead. What? Then why did they even bother with HSetVol if you're not supposed to use it? If I recall, all that needs to be done is set ioFVersNum to zero before calling PBHSetVol. Surely the glue code takes care of this for you when you want to use HSetVol. Tom... Tommy... Thomas... the Tom-ster, the Tom-boy, the Tomminator... ... Tom Shores, Department of Mathematics, University of Nebraska. ... shores@fergvax.unl.edu
francis@zaphod.uchicago.edu (Francis Stracke) (06/27/91)
In article <54370@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >There are only two reasons for creating working directories: >- If you are launching another application that expects to find its > location by making a GetVol call. >- If you are writing a hack that involves part of the system that > still uses working directories. For example, one person was > patching StdFile and needed to create WD's. Another person > wanted to fake out INIT 31 and needed to create WD's. Is there some way, prior to Sys7, to open a resource file (i.e., for resources, not just the resource fork) without a WD? -- /============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | What do you get if you multiply 6 by 9? | | francis@zaphod.uchicago.edu | --Ultimate Question | \============================================================================/
schorsch@oxy.edu (Brent William Schorsch) (06/27/91)
John Cavallino says
>could always have called _SetVol or _HSetVol (yes, I know) before...
Dont for get that you can get by with HSetVol if you bracket it with
GetVol(0, &savedRefNum)... ...SetVol(0, savedRefNum);finnegan@dhw68k.cts.com (Greg Finnegan) (06/27/91)
>There are only two reasons for creating working directories: > >- If you are launching another application that expects to find its > location by making a GetVol call. >- If you are writing a hack that involves part of the system that > still uses working directories. For example, one person was > patching StdFile and needed to create WD's. Another person > wanted to fake out INIT 31 and needed to create WD's. I can think of one more: if you are using someone else's commercial library which was written a few years ago and it requires a wdRefNum for some of its file calls (probably assuming the library would be called immediately after a Std File call). Greg. -- uucp: ...{spsd,zardoz,felix}!dhw68k!finnegan InterNet: finnegan@dhw68k.cts.com --------------------------------------------
zben@ni.umd.edu (Ben Cranston) (06/28/91)
In article <54370@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > There are only two reasons for creating working directories: > - If you are launching another application that expects to find its > location by making a GetVol call. > - If you are writing a hack that involves part of the system that > still uses working directories. For example, one person was > patching StdFile and needed to create WD's. Another person > wanted to fake out INIT 31 and needed to create WD's. Before System 7 it was necessary to create a WD if you wanted to open a resource file with the resource manager. Neither the old OpenResFile nor the newer OpenRFPerm routine takes a directory ID. Now that System 7 is here there is an HOpenResFile that is very much like OpenRFPerm with an added DirID parameter. I suspect this was added more for orthagonality and completeness, since the new FSpOpenResFile is clearly the only call a sane programmer would use (well, maybe that's not true -- if you have the filename in a separate buffer why copy it into an FSSpec record...). DE KA3ZDF K
jcav@quads.uchicago.edu (john cavallino) (06/28/91)
In article <1991Jun27.182325.3166@ni.umd.edu> zben@ni.umd.edu (Ben Cranston) writes: >Before System 7 it was necessary to create a WD if you wanted to open a >resource file with the resource manager. Neither the old OpenResFile nor >the newer OpenRFPerm routine takes a directory ID. Now that System 7 is >here there is an HOpenResFile that is very much like OpenRFPerm with an >added DirID parameter. This is not correct. _HOpenResFile and _HCreateResFile were introduced as glue in MPW 3.0. The newer versions of the THINK languages have the glue also. It works fine under System 6.x, and probably under any HFS system. Plus, you could always have called _SetVol or _HSetVol (yes, I know) before calling _OpenResFile. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ c+ g+ k s+(+) e+ h- pv (qv) | Telephone: 312-702-6900
keith@Apple.COM (Keith Rollin) (06/28/91)
In article <14699@dog.ee.lbl.gov> eastman@csa2.lbl.gov writes: >In article <1991Jun26.084825.9019@dartvax.dartmouth.edu>, llama@eleazar.dartmouth.edu (Joe Francis) writes... >>chuck@brain.UUCP (Chuck Shotton) writes: >> >>>Given the raft of Tech Notes on the subject, and the general noise concerning >>>them, I get the impression that Working Directories have fallen from grace. >>>Do they serve a purpose anymore? Why would I ever use one? (This IS a serious >>>question.) >> >>In answer to why would you ever use one... >> >>Before there were the new high level file manager calls (doc'd in a tech >>note, then put in IM VI), the only way I know of to take a Volume Name, >>Dir ID, and File Name and manage to open that file is to open a working >>directory. I would LOVE to be proven wrong on this, so please post any >>alternatives (given the above assumptions). >> > >Let us also not forget tech note #140, "Why PBHSetVol is Dangerous", wherein >we learn that using _HSetVol to change the default directory is a no-no. If >you want to change the default directory to a given vRefNum+dirID, and you >want to be compatible with all post-HFS systems, you have to compose a working >directory and pass it to PBSetVol instead. > >I presume the bad behavior has been fixed in some more recent version of the >System, but I haven't seen a revised TN 140 that tells me so. Am I wrong? Jack, I don't think that you read Technote #140 all the way through. The problem with HSetVol has to do with compatability with applications programmed for pre-HFS systems. It has nothing to do with being compatible with post-HFS systems. Since there is nothing Apple can do about "fixing" old applications, there's nothing that can be done in a "more recent version of the system" to fix the problem. By the way, there's nothing wrong with using HSetVol. Just don't leave the default directory set to that directory. For example, HOpenResFile uses HSetVol. However, before it returns, it carefully restores the default directory back to its previous setting. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
keith@Apple.COM (Keith Rollin) (06/28/91)
In article <shores.677989183@fergvax> shores@fergvax.unl.edu (Shores) writes: >In <14699@dog.ee.lbl.gov> eastman@csa2.lbl.gov (JACK EASTMAN) writes: >>Let us also not forget tech note #140, "Why PBHSetVol is Dangerous", wherein >>we learn that using _HSetVol to change the default directory is a no-no. If >>you want to change the default directory to a given vRefNum+dirID, and you >>want to be compatible with all post-HFS systems, you have to compose a working >>directory and pass it to PBSetVol instead. > >What? Then why did they even bother with HSetVol if you're not supposed >to use it? If I recall, all that needs to be done is set ioFVersNum to >zero before calling PBHSetVol. Surely the glue code takes care of this >for you when you want to use HSetVol. Tom, You recall incorrectly. The problems with HSetVol have nothing to do with ioFVersNum. They have to do with setting the default directory to a directory that doesn't have a corresponding working directory (did I say "directory" enough times?). -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
keith@Apple.COM (Keith Rollin) (06/28/91)
In article <FRANCIS.91Jun26225155@math.uchicago.edu> francis@zaphod.uchicago.edu (Francis Stracke) writes: >In article <54370@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > >>There are only two reasons for creating working directories: > >>- If you are launching another application that expects to find its >> location by making a GetVol call. >>- If you are writing a hack that involves part of the system that >> still uses working directories. For example, one person was >> patching StdFile and needed to create WD's. Another person >> wanted to fake out INIT 31 and needed to create WD's. > >Is there some way, prior to Sys7, to open a resource file (i.e., for >resources, not just the resource fork) without a WD? Yes. It's called HOpenResFile. It was included in MPW 3.0, and was documented in a technote about 3 years ago. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
keith@Apple.COM (Keith Rollin) (06/28/91)
In article <1991Jun27.162709.14957@dhw68k.cts.com> finnegan@dhw68k.cts.com (Greg Finnegan) writes: >>There are only two reasons for creating working directories: >> >>- If you are launching another application that expects to find its >> location by making a GetVol call. >>- If you are writing a hack that involves part of the system that >> still uses working directories. For example, one person was >> patching StdFile and needed to create WD's. Another person >> wanted to fake out INIT 31 and needed to create WD's. > >I can think of one more: if you are using someone else's commercial >library which was written a few years ago and it requires a wdRefNum >for some of its file calls (probably assuming the library would be >called immediately after a Std File call). This is a good and valid point. As a matter of fact, MacApp 2.0.1 suffers from this, too. There is at least one routine (MAOpenfile) that requires a working directory ID. All knowledge of working directories are being excised from MacApp 3.0, except where it has to convert the WD it gets back from StdFile. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
James.W.Matthews@dartmouth.edu (James W. Matthews) (06/28/91)
In article <1991Jun27.182325.3166@ni.umd.edu> zben@ni.umd.edu (Ben Cranston) writes: > Now that System 7 is > here there is an HOpenResFile that is very much like OpenRFPerm with an > added DirID parameter. I suspect this was added more for orthagonality > and completeness, since the new FSpOpenResFile is clearly the only call > a sane programmer would use.... That was my impression too, until I discovered that (unlike HOpenResFile) FSpOpenResFile is not implemented in glue, and therefore is not available on pre-7.0 systems. I like to use FSSpecs internally but I think I'm going to be passing them to HCreate, HOpen, HOpenResFile, et al. for quite a while.... Jim Matthews Dartmouth Software Development
lsr@Apple.COM (Larry Rosenstein) (06/29/91)
In article <1991Jun26.084825.9019@dartvax.dartmouth.edu> llama@eleazar.dartmouth.edu (Joe Francis) writes: >They high level HFS call HOpen, (TN 218, IM VI) takes a Dir ID directly. >The tech note indicates that the call is provided in glue for MPW 3.0+, >so presumeably it will work with any HFS system. HOpen calls PBHOpen which takes a (true) volume refnum, dirID, and name and opens the file. You can call PBHOpen directly if desired. This stuff is documented in Inside Mac 4. Opening a resource file given a volume refnum, dirID, and name is trickier. MPW does have glue code for HOpenResFile, which does this (I think). The 3.2 glue code calls System 7 HOpenResFile if it exists. Otherwise it uses HSetVol to set the current directory and calls OpenRFPerm. (The glue code seems to be careful about how it restored the current directory, to avoid the problems HSetVol can cause.) Neither case creates a working directory. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
ollef@sics.se (Olle Furberg) (06/30/91)
In <14312@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >Opening a resource file given a volume refnum, dirID, and name is trickier. Why? What's wrong with PBHOpenRF? According to IM IV p. 137: "PBHOpenRF is identical to PBOpenRF except that it accepts a directory ID in ioDirID." FUNCTION PBHOpenRF (paramBlock: HParmBlkPtr; async: BOOLEAN) : OSErr; Trap macro _HOpenRF Parameter block -> 12 ioCompletion pointer <- 16 ioResult word -> 18 ioNamePtr pointer -> 22 ioVRefNum word <- 24 ioRefNum word -> 27 ioPermssn byte -> 28 ioMisc pointer -> 48 ioDirID long word I'm sorry if I'm missing some fundamental fact. /Olle