Re: [NTLK] Newton packages versus OS X packages

From: David M. Ensteness (denstene_at_mac.com)
Date: Sun Feb 20 2005 - 14:17:44 PST


There seem to be a lot of misconceptions about Mac OS X going on here,
I don't know that this is the place for corrections or not ... but ...

>> Thankfully, Mac OS X still isn't Unix -- that's why I'm still using a
>> Mac.

Mac OS X *is* 100% Free BSD UNIX. Darwin, which is the core of the OS
includes a full distribution of Free BSD 4.5.

>> The Unix features already included in Mac OS X (except memory
>> protection and preemptive multitasking which every modern OS
>> supports) are bad enough.

I don't know what "UNIX features" Michael H. doesn't like ... its sorta
a hard thing to dislike if you know anything about em. And if you don't
know anything about them, its sorta hard to take your opinion
seriously.

I could go on for hours about the benefits and the lack of a real
downside but it would probably be better if someone said just *what* is
bad about Mac OS X being UNIX based.

>>> They are moving to a Unix model. Unix doesn't care about types and
>>> creators.

>> Anyway, one can support type and creator codes even with Mac OS X's
>> Unix underpinnings -- provided one wants to.

Apple *has* moved to UNIX. And correct, UNIX doesn't care about type
and creator codes because UNIX does not deal with forked files. No OS
but Classic Macintosh and Mac OS X understand forked files [maybe NOS
does, I do not think that BeOS does, UNIX/Linux/Windows do not].
However, forked files are THANKFULLY not going away.

Mac OS X maintains file extension compatibility, thanks to BSD and
NeXTSTEP, but also supports metadata in the form of type and creator
codes which are stored in the resource fork of a forked file.

I do not know enough about the Newton FS to know if Newton manages its
soups and packages via forked files, but I would suspect the primary
reason that Mac OS X often sees Newton packages as Mac OS X installer
packages is that in the current model a file extension *sometimes*
trumps the type and creator codes depending on the circumstance.

>> Note that the problem with Newton packages being mistaken for
>> application packages only arises because extensions are insufficient
>> for properly differentiating different types of files.
>>
> Or that type and creator get lost along the way.

The issue is that since Macintosh and Mac OS X are the only operating
systems that support forked files, non-Mac OS X UNIX/Linux systems,
Windows systems, etc ... all just ignore the resource fork and during a
file transfer the resource fork is not copied.

That is why if you use the UNIX command cp to copy a file its resource
fork is lost. And if you need some evidence that Apple *is not* getting
rid of type and creator codes, they also included the UNIX command
maccp (or is it cpmac, I can't seem to remember its exact name, not
sure if its included by default install but it is included with the dev
tools] which does copy the resource fork.

David

-- 
This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries
Official Newton FAQ: http://www.chuma.org/newton/faq/
WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/


This archive was generated by hypermail 2.1.5 : Sun Feb 20 2005 - 16:30:01 PST