Testing the waters for text/troff

[ned.freed at mrochek.com ([e-mail])]

> [I am not a Mac expert...]

I'm not either, but Mac OS X is the primary platform I work on, so I am at
least somewhat familiar with how this stuff works.

> At  4pm on 25/11/04 you (Bruce Lilly) wrote:
> >
> > In my search for "Macintosh File Type Code", I found one document
> > that mentions "File Type Codes", but that is specifically for Mac OS 9
> > and earlier, not for "Macintosh" in general (indeed, "Macintosh"
> > appears nowhere in that document (
> > http://docs.info.apple.com/article.html?artnum=55381
> > )).

> Yes. Mac OS X and Mac OS Classic (9 and earlier) are completely separate
> operating systems that happen to look similar. OSX is a perfectly normal
> BSDish system with a GUI derived from NeXTStep on top of it. AFAIK OSX
> doesn't use the Classic file type codes at all,

Actually, it does use them, although it also uses file name extensions. The
results can get to be a bit messy - I cited a web page in a previous post that
discusses this issue to some extent. Note that the messiness has more to do
with the fact that some applications pay attention to type codes while others
pay attention to file name extensions than it does to any confusion at the OS
level.

Creator codes are used much more extensively than type codes. However, this is
also true of Mac OS 9. Of course this is just common sense: A given file _type_
may be of interest to many applications, but a creator code binds a file to a
specific application. Specific information trumps general information.

> though what it does do
> by way of 'file associations' I'm not sure. I *certainly* hope it
> doesn't use file extensions...

Mac OS X understands file extensions and handles them specially, but AFAIK it
does not use them to associate an application with a file. That's still done
with type and creator codes. Of course this doesn't prevent specific
applications from doing this, and in fact that's exactly what happens. Mozilla
on Mac OS X, for example, has a table that maps either MIME types or file name
extensions to creator codes.

In case you care, here's a discussion of file name extension handling
in Mac OS X:

  http://cocoa.mamasam.com/COCOADEV/2001/09/1/11740.php

I will also point out that Mac OS X has various security features
surrounding double clicking on files that at least attempt to prevent
bad things from happening.

> > On Wed November 24 2004 15:40, Ben Morrow wrote:
> > >
> > > In your case, as *roff is unused on Apple systems, you could simply
> > > state that there is no Apple type code.
> >
> > I'm not so sure about that; I have seen literally dozens of references
> > to troff on Apple systems (all seem to refer to "Mac OS X"), so it's
> > certainly not true that "*roff is unused on Apple systems".  I recall
> > an Apple UNIX-based system called "Lisa" a few years back, and I
> > know of several versions of troff packages for a variety of platforms,
> > so I would not be at all surprised to find pre-OS-X troff on Apple
> > systems.

> This is all true; however, the Mac file type codes are only relevant to
> Mac OS Classic, which very rarely has *roff installed.

They aren't. See above.

> > Aside from this specific exercise, there are broader issues that should
> > be addressed in the media type registration form:
> > 1. If what is meant by "Macintosh File Type Code" is in fact
> >     "Mac OS 9 File Type Code" it would help if the registration
> >    template were revised to say so.  It's too late to help me for
> >    this case, but it might save others many hours of fruitless
> >    searching.

> This I would definitely agree with.

I don't because it is based on an incorrect conclusion.

> > 2. It would also help if there were a pointer to a definitive source
> >     of information for these OS-specific, platform-specific codes.
> > As the registration procedure and template seem to be undergoing
> > an update (draft-freed-media-type-reg-01.txt), that might be a good
> > opportunity to clarify such issues (or perhaps to elide that
> > idiosyncratic item altogether).

> No, that would be a bad idea, at least until Classic is firmly in the
> dustbin of history (I don't think it's quite there, yet).

It most certainly isn't, and isn't likely to be for a very long time. I know
plenty of people who still use OS 9 and I know of applications people depend on
that haven't been ported to OS X yet.

> Any sane
> system of file type identifications would use MIME types directly;

Agreed, but sadly that's not how things work in practice. And our security
is the worse for it.

				Ned