Re: creating a resource fork and writing raw bytes to it
Re: creating a resource fork and writing raw bytes to it
- Subject: Re: creating a resource fork and writing raw bytes to it
- From: Charles Srstka <email@hidden>
- Date: Thu, 22 May 2008 00:50:31 -0500
On May 22, 2008, at 12:09 AM, Mike Fischer wrote:
As I understand it only the GUI portions of Carbon are going out of
style. The lower level stuff like the File Manager seems to be
sticking around. (Well not the old FSSpec stuff but the modern FSRef
APIs.) Actually it seems like some things are being moved from
Carbon -> CoreServices to make the distinction.
For now. But as Cocoa becomes more and more the "accepted" framework
for writing applications, the future of even the non-GUI parts of
Carbon come into question, in my view. What becomes the purpose of the
Carbon File Manager, anyway? Cocoa's already got a file manager. And
yet even after seven years, with all the new APIs, new language
features, and new paradigms that have been added to Cocoa, its file
manager still has absolutely no support for forks or anything non-path
based.
Remember that not that long ago we all thought Carbon was going to be
64-bit in Leopard. It's all speculation, but my interpretation of all
this is that there's been a battle going on inside Apple, between a
Carbon/MacOS/FSRefs/Aliases faction and a Cocoa/NeXT/flat files/path-
based faction, and what we saw there was the final defeat of the
Carbon faction. I'm not really sure what the future holds.
Anyway I remember reading somewhere that Apple warned about relying
on ..namedfork/rsrc always working. I can't find the reference at
the moment though.
That was WWDC 2006, in which the speaker for one of the sessions
commented that the /rsrc hack was going to be removed from Leopard. It
didn't say anything about ..namedfork, though - just /rsrc, which I
don't think anyone really uses anymore. Of course, /rsrc still works
in Leopard, so who knows.
There are other reasons to favor the File Manager over path based
APIs. One would be more robust behaviour in the face of moving files
and folders. Another would be avoidance of PATH_MAX problems.
True, but I don't think the people currently in charge are big fans of
these sorts of features.
Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden