Re: Cocoa stripping resource forks: does Jaguar fix?
Re: Cocoa stripping resource forks: does Jaguar fix?
- Subject: Re: Cocoa stripping resource forks: does Jaguar fix?
- From: Sam Griffith <email@hidden>
- Date: Wed, 03 Jul 2002 17:52:02 -0500
On 7/3/02 4:58 PM, "Sam Griffith" <email@hidden> wrote:
>
From what I remember, resource forks are going away. I seem to remember Apple
>
saying that at one of the developers conferences.
>
This is from what I remember. I'm just getting back into programming on the
Mac after having done so from 1984-1989 and then the NeXT from 1989 - 1996.
I'm just getting back in so I might have a few things off, but for the most
part I think this is an ok overview. Those who know more please add to
this..... :-)
***** How it was and is in System 1.0 - 9.2 *****
Resources are now dealt with in a more portable way. Let me see if I can
explain a bit, since I haven't read the whole thread, I might repeat stuff
but please indulge me on this.
Resources and the forked file system on the Mac were created back in 1982-3
and at the time it was a great idea. It's purpose was to make it so that
when you installed an application, everything was in one little package. The
code would be on one side of the file and the resources were on the other
side of the file and the code side get get references via name, id, etc.
This at the time was a big deal! It had the advantages that icons, picts,
etc. could be changed without recompiling code, etc. and you didn't have
things in different folders, etc. The Finder didn't have to hide things
from you about what an application really was. An app was the file with the
two different forks.
***** Issues with that *****
The problem with a forked file system was that no one else in the world did
it that way and when you copied a file to another machine (via disk, the
net, etc.) they didn't know the data structure of the Mac file system and so
didn't read the resource fork. (This is what the basis of the thread is
about - things being stripped off)
As things in the Mac world grew and changed the transparency of the idea
started to fail as we had extensions, dynamically loadable libraries, etc.
Apps would get installed in a folder and then each little component was
either in that folder or a subfolder or in the extensions folder of the
system. Each one of these had a code fork and a resource fork. This
evolution while keeping resources as a helpful idea, lost the idea that an
app and all it needed were just dragged in. Now things are viewable and the
Finder still only hid the resource fork, but all the little components were
visible. So you could mess up an install by moving a component, what ever.
Other systems although having the possibility of supporting multi-forked
files, never did. (Windows NTFS comes to mind)
***** NeXT and Cocoa and OS X *****
That said, lets talk about the history of files on the NeXT and then OS X.
(This is somewhat from old memory as far as NeXT is concerned). The NeXT
people (many of whom are the same people who worked on the LISA Toolkit -
notice the similarity to the NeXT AppKit) knew that on the rest of the OS's
out there that they had to have a flat file based organization for the code
and resources for portability and re-use of existing work done on the OS
that they were based on - ie. Unix.
They also had learned a few things while working on the Mac and the LISA and
the NeXT version called OpenStep that was ported to Sun OS, Windows NT and
HP UX. They learned that it would be easier to organize the resources and
libraries in a new way. And in fact a way that is completely compatible
with flat file systems. They do this by having things like packages,
lproj's, frameworks, etc.
They also realized that the have control over the user experience and
Workspace/Finder and so they can use that level of the interface to complete
the illusion that there aren't those sub-directories with all those code and
resource files. They do this my having the Workspace (or in OS X the Finder)
know about the organization of the file system and special file types as far
as what they want to hide. This is similar to the old Finder not showing the
resource fork as part of a file.
You can see this in OS X by cntrl-clicking on an application and then
choosing "Open package contents". This is the equivalent to seeing the two
different sides of an old Mac app. You can see the code parts and the
resource parts. Also, you see lproj files. These are specific projects for
each different language area. Spanish, Japanese, etc.
So you get all the power of resource forks, better organization, more hiding
of things that should be hidden and finally, we are back to single file
install for apps. (That is if it isn't an old Carbon upgraded app - they
still are in the middle land.)
***** So what does this mean *****
From a post:
>
For example, I don't see, since other OS cannot have previews and custom
>
> icons for graphic files, why I should not use them on my Mac which is able
>
> to do this...
Using the ideas I just stated, you can have the Finder use a non-forked file
system to give custom icons, previews, etc. without resource forks, by
letting the Finder know how about files and there organization. It doesn't
not seem that OS X's Finder does this though. It seems to have a
combination of both approaches. (Best of both worlds maybe?)
What will happen? I don't know, but I wanted to share a bit about how
things are or got to be.
Hope this has been a bit informative.
--
Sam Griffith Jr.
email: email@hidden
Web site:
http://homepage.mac.com/staypufd/index.html
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.