Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!reed!glacier!busker!f20.n226.z1.FIDONET.ORG!David.Hairston
From: David.Hairston@f20.n226.z1.FIDONET.ORG (David Hairston)
Newsgroups: comp.sys.mac.programmer
Subject: Re: stdio, THINK C and APPLs
Message-ID: <641.2783DEFC@busker.fidonet.org>
Date: 28 Dec 90 03:59:20 GMT
Sender: ufgate@busker.fidonet.org (newsout1.26)
Organization: FidoNet node 1:226/20 - cmhGate UF Gateway, Columbus OH
Lines: 33

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.ORG