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: Rosyna <email@hidden>
- Date: Wed, 3 Jul 2002 19:50:41 -0700
Ack, at 7/3/02, Sam Griffith said:
***** 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)
Not really, PC Exchange copied the resource fork over as
AppleSingle/AppleDouble format. The same thing they did for that A/UX
thing. The documentation for the format is on the developer CDs in
the Tools and Utilities folder and at
ftp://ftp.apple.com/developer/Tool_Chest/Networking_-_Communications/AppleSingle_AppleDouble_For.sit.hqx
(I have *no* clue what file format this is in, maybe MacWrite)
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.
The code for the actual application in the 68k days was in the
Resource fork. This limited the single application file to 16megs (a
resource fork could be no bigger than that size) And the TOC limit
for a CFM application, made with Metworks CodeWarrior Pro 7 and below
and maybe some other compilers/IDEs, is 64k (I am told CW Pro 8 lets
you set an arbitrary size up to fill memory.) Both of these make
shared libraries necessary. Reusable code makes it increasingly
recommended.
Other systems although having the possibility of supporting multi-forked
files, never did. (Windows NTFS comes to mind)
It does when Services for Macintosh is installed on Win 2k and Win NT
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.
And how exactly do you send an rtfd to a windows user? or any bundle
to anyone via email? It shows as a file to the user, but it's not?
WTH? ;)
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.
The resource fork and the data fork were *one* file on HFS based
systems. It's only on other file systems that it appears as two files
for compatibility reasons.
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.
You never would see the two different sides of an old mac app. All
the old mac apps you would have been familiar with were 68k and all
data was stored in the resource fork. This allowed for Windows/68k
binaries in the *same* file. How's that for compatibility? ;) Apple
made some recommendations for usage of the resource fork.
(
http://developer.apple.com/technotes/fl/fl_19.html called "Data in
Resource Fork: Don't Do it" from 1986)
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.)
It's a single file when users see a bunch of file names they have
never heard of being prepared to copy in the finder? (Talkin about
OmniWeb here) ;)
***** 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?)
And how do you do that with a jpeg image or gif image *and keep it
compatible* with windows viewers?
This thread is pointless and off-topic any ways. It has been gone
over 100s of times on different lists and no one ever changes their
mind or learns anything from it. Programmers can be extremely
stubborn and close-minded. Especially if they have decades of
experience.
The point is, whether you like the data or not, do *not* destroy
*any* kind of data. This include bundle bits, dates, resource forks,
long file names, type/creator code info, and the like. You never know
when some user might have an important password or something of the
like in one of these places or some other important data that they
could lose and sue you for destroying
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
---
Please include any previous correspondence in replies, it helps me
remember what we were talking about. Thanks.
_______________________________________________
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.