vladimir@prosper.EBB.Eng.Sun.COM (Vladimir G. Ivanovic) (12/24/90)
As far as I can tell, THINK C's implementation of stdio will not read anything
from a file of type APPL. I've tried opening an application with both fopen()
with "r" and "rb", and with open() with O_BINARY (the default) without
success. No errors are returned by any call, just 0 bytes are read.
Is my assumption that since there is no data fork, stdio thinks it's has a
zero length file correct? Or am I doing something wrong? Does that mean I
have to use Toolbox calls to copy an application?
If the data fork assumption is correct, is this The Way It Should Be? How
does MPW C behave?
-- Vladimir, the Puzzled.
--
==============================================================================
Vladimir G. Ivanovic Sun Microsystems, Inc
(415) 336-2315 2550 Garcia Ave., MTV12-33
vladimir@Sun.COM Mountain View, CA 94043-1100
Disclaimer: I speak only for myself. Your mileage will vary.
==============================================================================hairston@henry.ece.cmu.edu (David Hairston) (12/25/90)
[vladimir@prosper.EBB.Eng.Sun.COM (Vladimir G. Ivanovic) writes:] [] As far as I can tell, THINK C's implementation of stdio will not read [] anything from a file of type APPL. I've tried opening an application [] with both fopen() with "r" and "rb", and with open() with O_BINARY (the [] default) without success. No errors are returned by any call, just 0 [] bytes are read. [] [] Is my assumption that since there is no data fork, stdio thinks it's has a [] zero length file correct? Or am I doing something wrong? Does that mean I [] have to use Toolbox calls to copy an application? stdio calls access the data fork of a file. typically, in an APPL all the interesting stuff is in the resource fork and the data fork is empty. there are toolbox calls that manipulate the resource fork in the way that you want. you might want to read Inside Macintosh I, chap. 5, The Resource Manager to get a better understanding of this. mac files are distinctly different than the concept of a file on, for example, unix. happy holidys, one and all! -dave- hairston@henry.ece.cmu.edu
daven@svc.portal.com (12/25/90)
In article <VLADIMIR.90Dec23224539@prosper.EBB.Eng.Sun.COM> vladimir@prosper.EBB.Eng.Sun.COM (Vladimir G. Ivanovic) writes: >As far as I can tell, THINK C's implementation of stdio will not read anything >from a file of type APPL. I've tried opening an application with both fopen() >with "r" and "rb", and with open() with O_BINARY (the default) without >success. No errors are returned by any call, just 0 bytes are read. > >Is my assumption that since there is no data fork, stdio thinks it's has a >zero length file correct? Or am I doing something wrong? Does that mean I >have to use Toolbox calls to copy an application? Bingo! There's no data fork, so there's no data to read. >If the data fork assumption is correct, is this The Way It Should Be? How >does MPW C behave? This is The Way It Should Be! Imagine if everytime you used fopen() it returned to you the contents of a) the data fork, or b) the resource fork, or c) both. You'd have no way of knowing what you'd get. Instead, it was decided that only the data fork contents would be read. If you want to get to the resource fork, you'll have to make Mac file system calls. -- ------------------------------------------------------------------------------- Dave Newman | daven@svc.portal.com | AppleLink: D0025 Sofware Ventures Corp. | AOL: MicroPhone | CIS: 76004,2161 Berkeley, CA 94705 | WELL: tinman@well.sf.ca.us | (415) 644-3232
dorner@pequod.cso.uiuc.edu (Steve Dorner) (12/28/90)
In article <1990Dec24.182548.17958@svc.portal.com> daven@svc.portal.com writes: >>If the data fork assumption is correct, is this The Way It Should Be? How >This is The Way It Should Be! Horse puppies! It would be easy enough to add another file "mode" to fopen (and another flag bit to open), to give you the choice of data or resource forks. I wonder why the library writers don't do it? -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
hairston@henry.ece.cmu.edu (David Hairston) (12/28/90)
[dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:] [] >>If the data fork assumption is correct, is this The Way It Should Be? [] >This is The Way It Should Be! [] [] Horse puppies! [] [] It would be easy enough to add another file "mode" to fopen (and another [] flag bit to open), to give you the choice of data or resource forks. I [] wonder why the library writers don't do it? sure that would be easy ... but fopen/open etc. come from the worlds where files are described in the tradition way. they are expected to work in those worlds and the data fork is analogous to the traditional concept of a file so they should operate exclusively on the data fork. the resource fork isn't simply another fork to be manipulated in the manner of the data fork. manipulating the resource fork properly demands special tools since it is so intertwined with MacOS. in an abstract sense, i guess it could be argued that the resource fork is merely a specialized folder (or directory) structure and therefore should be accessible by fopen/open but i think that analogy is a little too simple and misleading (IMO). -dave- hairston@henry.ece.cmu.edu
d88-jwa@nada.kth.se (Jon W{tte) (12/28/90)
In article <> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >>>If the data fork assumption is correct, is this The Way It Should Be? How >>This is The Way It Should Be! >Horse puppies! Well, Apple has told us not to use the resource fork for data, but just to use the Resource Manager calls. Opening the resource fork as a normal data file might be too tempting for some :-) As it says in TechNote <something> - the OpenRF calls are only provided for people who want to a) try and correct corrupted resource forks or b) copy a resource file in whole. This is just as well done using Mac ToolBox calls. H+ -- Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
keith@Apple.COM (Keith Rollin) (12/28/90)
In article <1990Dec27.183436.3786@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >In article <1990Dec24.182548.17958@svc.portal.com> daven@svc.portal.com writes: >>>If the data fork assumption is correct, is this The Way It Should Be? How >>This is The Way It Should Be! > >Horse puppies! > >It would be easy enough to add another file "mode" to fopen (and another >flag bit to open), to give you the choice of data or resource forks. I wonder >why the library writers don't do it? Because the resource fork should be read ONLY with the the Resource Manager. Unless, of course, you are writing some sort of resource fork diagnostic program. In which case you aren't going to be portable anyway, and could easily use the File Manager calls. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
Steve.Dorner@f20.n226.z1.FIDONET.ORG (Steve Dorner) (12/28/90)
Reply-To: dorner@pequod.cso.uiuc.edu In article <1990Dec24.182548.17958@svc.portal.com> daven@svc.portal.com writes: >>If the data fork assumption is correct, is this The Way It Should Be? How >This is The Way It Should Be! Horse puppies! It would be easy enough to add another file "mode" to fopen (and another flag bit to open), to give you the choice of data or resource forks. I wonder why the library writers don't do it? -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner + Organization: University of Illinois at U-C -- Steve Dorner - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Steve.Dorner INTERNET: Steve.Dorner@f20.n226.z1.FIDONET.ORG
siegel@endor.uucp (Rich Siegel) (12/28/90)
In article <1990Dec27.183436.3786@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > >It would be easy enough to add another file "mode" to fopen (and another >flag bit to open), to give you the choice of data or resource forks. I wonder >why the library writers don't do it? Perhaps because it isn't ANSI-conformant...? R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "...she's dressed in yellow, she says 'Hello, come sit next to me, you fine fellow..."
David.Hairston@f20.n226.z1.FIDONET.ORG (David Hairston) (12/28/90)
Reply-To: hairston@henry.ece.cmu.edu
[dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:]
[] >>If the data fork assumption is correct, is this The Way It Should Be?
[] >This is The Way It Should Be!
[]
[] Horse puppies!
[]
[] It would be easy enough to add another file "mode" to fopen (and another
[] flag bit to open), to give you the choice of data or resource forks. I
[] wonder why the library writers don't do it?
sure that would be easy ... but fopen/open etc. come from the worlds
where files are described in the tradition way. they are expected to
work in those worlds and the data fork is analogous to the traditional
concept of a file so they should operate exclusively on the data fork.
the resource fork isn't simply another fork to be manipulated in the
manner of the data fork. manipulating the resource fork properly
demands special tools since it is so intertwined with MacOS. in an
abstract sense, i guess it could be argued that the resource fork is
merely a specialized folder (or directory) structure and therefore
should be accessible by fopen/open but i think that analogy is a little
too simple and misleading (IMO).
-dave-
hairston@henry.ece.cmu.edu
+ Organization: Gaia II
--
David Hairston - via FidoNet node 1:105/14
UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!David.Hairston
INTERNET: David.Hairston@f20.n226.z1.FIDONET.ORGJon.W{tte@f20.n226.z1.FIDONET.ORG (Jon W{tte) (12/28/90)
Reply-To: d88-jwa@nada.kth.se In article <> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >>>If the data fork assumption is correct, is this The Way It Should Be? How >>This is The Way It Should Be! >Horse puppies! Well, Apple has told us not to use the resource fork for data, but just to use the Resource Manager calls. Opening the resource fork as a normal data file might be too tempting for some :-) As it says in TechNote <something> - the OpenRF calls are only provided for people who want to a) try and correct corrupted resource forks or b) copy a resource file in whole. This is just as well done using Mac ToolBox calls. H+ -- Jon W{tte, Stockholm, Sweden, h+@nada.kth.se + Organization: Royal Institute of Technology, Stockholm, Sweden -- Jon W{tte - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Jon.W{tte INTERNET: Jon.W{tte@f20.n226.z1.FIDONET.ORG
Keith.Rollin@f20.n226.z1.FIDONET.ORG (Keith Rollin) (12/28/90)
Reply-To: keith@Apple.COM In article <1990Dec27.183436.3786@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >In article <1990Dec24.182548.17958@svc.portal.com> daven@svc.portal.com writes: >>>If the data fork assumption is correct, is this The Way It Should Be? How >>This is The Way It Should Be! > >Horse puppies! > >It would be easy enough to add another file "mode" to fopen (and another >flag bit to open), to give you the choice of data or resource forks. I wonder >why the library writers don't do it? Because the resource fork should be read ONLY with the the Resource Manager. Unless, of course, you are writing some sort of resource fork diagnostic program. In which case you aren't going to be portable anyway, and could easily use the File Manager calls. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions + Organization: Apple Computer Inc., Cupertino, CA -- Keith Rollin - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Keith.Rollin INTERNET: Keith.Rollin@f20.n226.z1.FIDONET.ORG
Rich.Siegel@f20.n226.z1.FIDONET.ORG (Rich Siegel) (12/28/90)
From: siegel@endor.uucp Reply-To: siegel@endor.UUCP In article <1990Dec27.183436.3786@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > >It would be easy enough to add another file "mode" to fopen (and another >flag bit to open), to give you the choice of data or resource forks. I wonder >why the library writers don't do it? Perhaps because it isn't ANSI-conformant...? R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "...she's dressed in yellow, she says 'Hello, come sit next to me, you fine fellow..." + Organization: Symantec Language Products Group -- Rich Siegel - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Rich.Siegel INTERNET: Rich.Siegel@f20.n226.z1.FIDONET.ORG
dorner@pequod.cso.uiuc.edu (Steve Dorner) (12/29/90)
In article <47608@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >Because the resource fork should be read ONLY with the the Resource >Manager. Horse puppies, again. Apple provides OpenRF, and allows the reference number thus returned to be used in any of the file manager functions (read, write, etc). I see NO reason why this behavior shouldn't be exactly mirrored in the C library. If it was good enough to put in ROM, it's good enough to add the half-dozen lines of code to open and fopen to make it available to them as well. We're not talking about a large investment in time or code size. Arbitrary restrictions are almost always a bad idea. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
dorner@pequod.cso.uiuc.edu (Steve Dorner) (12/29/90)
In article <5173@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <1990Dec27.183436.3786@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >> >>It would be easy enough to add another file "mode" to fopen (and another >>flag bit to open), to give you the choice of data or resource forks. I wonder >>why the library writers don't do it? > > Perhaps because it isn't ANSI-conformant...? Then remove \p from string constants, and %P from printf, 'cause they aren't in the ANSI spec, either. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
peter@hari.Viewlogic.COM (Peter Colby) (12/29/90)
In article <1990Dec28.162334.20490@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: |> In article <47608@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: |> >Because the resource fork should be read ONLY with the the Resource |> >Manager. |> |> Horse puppies, again. |> |> Apple provides OpenRF, and allows the reference number thus returned to |> be used in any of the file manager functions (read, write, etc). |> |> I see NO reason why this behavior shouldn't be exactly mirrored in the |> C library. If it was good enough to put in ROM, it's good enough to |> add the half-dozen lines of code to open and fopen to make it available to |> them as well. We're not talking about a large investment in time or |> code size. |> |> Arbitrary restrictions are almost always a bad idea. |> -- |> Steve Dorner, U of Illinois Computing Services Office |> Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner Well Good Grief! If it's that important to you, why don't you just fix the library yourself, to your specification. I believe that Symantic/THINK provides the source code to the ANSI libraries. Peter C. -- (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O) !the doctor is out! (O) (0) peter@viewlogic.com (0) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O)
Steve.Dorner@f20.n226.z1.FIDONET.ORG (Steve Dorner) (12/29/90)
Reply-To: dorner@pequod.cso.uiuc.edu In article <47608@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >Because the resource fork should be read ONLY with the the Resource >Manager. Horse puppies, again. Apple provides OpenRF, and allows the reference number thus returned to be used in any of the file manager functions (read, write, etc). I see NO reason why this behavior shouldn't be exactly mirrored in the C library. If it was good enough to put in ROM, it's good enough to add the half-dozen lines of code to open and fopen to make it available to them as well. We're not talking about a large investment in time or code size. Arbitrary restrictions are almost always a bad idea. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner + Organization: University of Illinois at U-C -- Steve Dorner - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Steve.Dorner INTERNET: Steve.Dorner@f20.n226.z1.FIDONET.ORG
Steve.Dorner@f20.n226.z1.FIDONET.ORG (Steve Dorner) (12/29/90)
Reply-To: dorner@pequod.cso.uiuc.edu In article <5173@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <1990Dec27.183436.3786@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >> >>It would be easy enough to add another file "mode" to fopen (and another >>flag bit to open), to give you the choice of data or resource forks. I wonder >>why the library writers don't do it? > > Perhaps because it isn't ANSI-conformant...? Then remove \p from string constants, and %P from printf, 'cause they aren't in the ANSI spec, either. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner + Organization: University of Illinois at U-C -- Steve Dorner - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Steve.Dorner INTERNET: Steve.Dorner@f20.n226.z1.FIDONET.ORG
Peter.Colby@f20.n226.z1.FIDONET.ORG (Peter Colby) (12/29/90)
Reply-To: peter@hari.Viewlogic.COM In article <1990Dec28.162334.20490@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: I> In article <47608@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: I> >Because the resource fork should be read ONLY with the the Resource I> >Manager. I> I> Horse puppies, again. I> I> Apple provides OpenRF, and allows the reference number thus returned to I> be used in any of the file manager functions (read, write, etc). I> I> I see NO reason why this behavior shouldn't be exactly mirrored in the I> C library. If it was good enough to put in ROM, it's good enough to I> add the half-dozen lines of code to open and fopen to make it available to I> them as well. We're not talking about a large investment in time or I> code size. I> I> Arbitrary restrictions are almost always a bad idea. I> -- I> Steve Dorner, U of Illinois Computing Services Office I> Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner Well Good Grief! If it's that important to you, why don't you just fix the library yourself, to your specification. I believe that Symantic/THINK provides the source code to the ANSI libraries. Peter C. -- (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O) !the doctor is out! (O) (0) peter@viewlogic.com (0) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O) + Organization: Viewlogic Systems, Inc., Marlboro, MA -- Peter Colby - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Peter.Colby INTERNET: Peter.Colby@f20.n226.z1.FIDONET.ORG
keith@Apple.COM (Keith Rollin) (12/29/90)
In article <1990Dec28.162334.20490@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >In article <47608@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >>Because the resource fork should be read ONLY with the the Resource >>Manager. > >Horse puppies, again. > >Apple provides OpenRF, and allows the reference number thus returned to >be used in any of the file manager functions (read, write, etc). > >I see NO reason why this behavior shouldn't be exactly mirrored in the >C library. If it was good enough to put in ROM, it's good enough to >add the half-dozen lines of code to open and fopen to make it available to >them as well. We're not talking about a large investment in time or >code size. > >Arbitrary restrictions are almost always a bad idea. But automatic mirroring of all ROM routines in the C Libraries isn't necessarily a good idea either. For instance, if you make a printf() call, it eventually calls DrawString. This doesn't mean that we should add an option to printf() that causes the libraries to call TextBox instead. And even if a routine is in ROM or implemented by the System and is documented in Inside Mac or a Technote, that doesn't mean that it should be called. For example, take InitGDevice or CheckUpdate. These are routines made available for completeness but it doesn't mean that you should try to find some place in your program to put them. They are there in case you really, really, really need them. Similarly with the OpenRF call. It's there if you really, really, really need it. However, that doesn't mean that you should call it on a whim, which some people might do if we made it easy to get at from fopen(). As was previously posted, use of OpenRF should be limited to applications that a) need to deal with corrupted resource forks, or b) need to copy a file. In either of these cases, you are writing non-portable code, and could just as easily use OpenRF rather than fopen(). As a matter of fact, using the File Manager for file I/O is MUCH better than using the C Libraries. Those libraries have a lot of generic AT&T junk in them, and include a LOT of overhead. For better performance, use the Mac File Manager routines. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (12/29/90)
David Hairston writes in a message to All
DH> in an abstract sense, i guess it could be argued that the resource
DH> fork is merely a specialized folder (or directory) structure
DH> and therefore should be accessible by fopen/open but i think
DH> that analogy is a little too simple and misleading (IMO).
Better to think of the resource fork as a specialized database file that only
the OS knows how to access properly. Maybe YOU can do it, but the OS knows the
innards better, so why try to do it yourself?
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgdaven@svc.portal.com (01/08/91)
In article <640.2783DEFA@busker.fidonet.org> Steve.Dorner@f20.n226.z1.FIDONET.ORG (Steve Dorner) writes: >Reply-To: dorner@pequod.cso.uiuc.edu > >In article <1990Dec24.182548.17958@svc.portal.com> daven@svc.portal.com writes: >>>If the data fork assumption is correct, is this The Way It Should Be? How >>This is The Way It Should Be! > >Horse puppies! > >It would be easy enough to add another file "mode" to fopen (and another >flag bit to open), to give you the choice of data or resource forks. I wonder >why the library writers don't do it? Well that hardly keeps within the spirit of portable C code, which is what I thought the moaning was all about. If you modify FOpen to have a new mode, then it's hardly portable. Opening a resource fork is a Mac OS specific function, and does not make sense on any other machine. Thus, use the Mac OS call to do this, that's what it's there for. Additionally, there's two ways to open a resource a resource - one as a just a plain file (dangerous!, very dangerous! unless you're planning on copying another entire resource fork over the one you just opened) - the other is where you open as an active resource fork and let the Resource Manager have told control over it's contents. -- ------------------------------------------------------------------------------- Dave Newman | daven@svc.portal.com | AppleLink: D0025 Sofware Ventures Corp. | AOL: MicroPhone | CIS: 76004,2161 Berkeley, CA 94705 | WELL: tinman@well.sf.ca.us | (415) 644-3232
daven@svc.portal.com (01/08/91)
In article <648.2783DF08@busker.fidonet.org> Rich.Siegel@f20.n226.z1.FIDONET.ORG (Rich Siegel) writes: >From: siegel@endor.uucp >Reply-To: siegel@endor.UUCP > >In article <1990Dec27.183436.3786@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu >(Steve Dorner) writes: >> >>It would be easy enough to add another file "mode" to fopen (and another >>flag bit to open), to give you the choice of data or resource forks. I wonder >>why the library writers don't do it? > > Perhaps because it isn't ANSI-conformant...? > Rich, you put it so well! ;-) -- ------------------------------------------------------------------------------- Dave Newman | daven@svc.portal.com | AppleLink: D0025 Sofware Ventures Corp. | AOL: MicroPhone | CIS: 76004,2161 Berkeley, CA 94705 | WELL: tinman@well.sf.ca.us | (415) 644-3232
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/09/91)
In article <1991Jan7.224021.9163@svc.portal.com> daven@svc.portal.com writes: >Well that hardly keeps within the spirit of portable C code, which is what >I thought the moaning was all about. If you modify FOpen to have a new >mode, then it's hardly portable. MPW C gives printf a new descriptor (%P); do you consider this evil? >Opening a resource fork is a Mac OS specific function, and does not make >sense on any other machine. Thus, use the Mac OS call to do this, that's >what it's there for. You are right that portability is not the issue here. Making life easier for C programmers is the issue here. The mac file manager is a complete mess [c'mon: dirid's, vref's, wdnums, PMSP, the PB calls (which you HAVE to use if you want to open a file with other than read/write permission)], and the less the novice HAS to know about it the better. >Additionally, there's two ways to open a resource a >resource - one as a just a plain file (dangerous!, very dangerous! unless >you're planning on copying another entire resource fork over the one you >just opened) Every single application that saves files should use this call. When you save a file, you write a new one, delete the old and rename the new. You should also copy the resource fork, in case there are tab/font settings or other interesting information (window position, maybe) in it. How many of you hate apps that don't preserve the resource fork? I'm not sure this is worth arguing about. I'm just irked that such an innocuous TRIVIAL and convenient extension isn't made. Again, I point you to "%P", which is of much the same nature. (Rich tells me that %P is gone from THINK C; that's too bad.) Or "\p" in strings. Care to remove that for the sake of ANSI compatibility? -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
d88-jwa@dront.nada.kth.se (Jon W{tte) (01/09/91)
In article <1991Jan8.160431.3537@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >[c'mon: dirid's, vref's, wdnums, PMSP, the PB calls (which you HAVE to >use if you want to open a file with other than read/write permission)], >and the less the novice HAS to know about it the better. HOpen ? HCreate ? HOpenResFile ? >How many of you hate apps that don't preserve the resource fork? What's wrong with SetEOF ( refNum , 0L ) ??? No messing with a delete that might use the PMSP, and preservation of the resource fork. H+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
bruner@sp15.csrd.uiuc.edu (John Bruner) (01/09/91)
Perhaps this has changed in the final version, but section 4.9.5.3 of the 7 December 1988 draft of the ANSI C standard says: Synopsis #include <stdio.h> FILE *fopen(const char *filename, const char *mode); Description The fopen function opens the file whose name is the string pointed to by filename and associates a string with it. The argument mode points to a string beginning with one of the following sequences: (footnote 112) ... Footnote 112 says "Additional characters may follow these sequences." In the Rationale (also section 4.9.5.3) it says ... An implementation may choose to allow additional file specifications as part of the mode string argument. For instance, file1 = fopen(file1name, "wb,reclen=80"); might be a reasonable way, on a system which provides record-oriented binary files, for an implementation to allow a programmer to specify record length. This brings the conclusion that an implementation that allows the resource fork to be fopen'ed by using some extra characters in the mode string would be ANSI-compliant. A program that uses such a feature will be portable only if the different C language implementations for the Mac all provide this extension in a mutually-compatible fashion. A program that manipulates the resource fork is not going to be portable to non-Mac platforms, regardless of whether or not it uses extensions to fopen(). -- John Bruner Center for Supercomputing R&D, University of Illinois bruner@csrd.uiuc.edu (217) 244-4476 -- John Bruner Center for Supercomputing R&D, University of Illinois bruner@csrd.uiuc.edu (217) 244-4476
minich@d.cs.okstate.edu (Robert Minich) (01/09/91)
by dorner@pequod.cso.uiuc.edu (Steve Dorner): | MPW C gives printf a new descriptor (%P); do you consider this evil? | No, but then again, programming on the Mac tends to throw you a lot more Pascal strrings than bare resource forks. :-) |>Opening a resource fork is a Mac OS specific function, and does not make |>sense on any other machine. Thus, use the Mac OS call to do this, that's |>what it's there for. | | You are right that portability is not the issue here. Making life easier | for C programmers is the issue here. The mac file manager is a complete mess | [c'mon: dirid's, vref's, wdnums, PMSP, the PB calls (which you HAVE to | use if you want to open a file with other than read/write permission)], | and the less the novice HAS to know about it the better. I still don't understand the need to much with the resource fork via stdio calls. Are you really that hard pressed to write that little bit (really, it's not THAT bad!) to read from the resource fork? |>Additionally, there's two ways to open a resource a |>resource - one as a just a plain file (dangerous!, very dangerous! unless |>you're planning on copying another entire resource fork over the one you |>just opened) | | Every single application that saves files should use this call. When | you save a file, you write a new one, delete the old and rename the new. | You should also copy the resource fork, in case there are tab/font settings | or other interesting information (window position, maybe) in it. | | How many of you hate apps that don't preserve the resource fork? I think your use of "save" is not clear. Do you mean "Save As..." on on open file or "Save" on a new or pre-existing file? If the former, I wouldn't worry about it too much since that's not a a Mac application. :-| If your talking about a plain "Save" on a pre-existing file, why do you have to go through the delete/rename motions? Just flat out copy the new data directly into the original file, after ensuring it will be able to save (Diskspace check.) | I'm not sure this is worth arguing about. I'm just irked that such an | innocuous TRIVIAL and convenient extension isn't made. Again, I point | you to "%P", which is of much the same nature. (Rich tells me that %P | is gone from THINK C; that's too bad.) Or "\p" in strings. Care to | remove that for the sake of ANSI compatibility? | -- If this is so trivial, then go ahead and do it yourself. If I recall corectly, you use THINK C, so you have the stdio source code. :-p -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| "I'm not discouraging others from using |=(___)= | minich@d.cs.okstate.edu | their power of the pen, but mine will | U | - "Ackphtth" | continue to do the crossword." M. Ho