Cameron Kaiser wrote: Where would you hide the creator attributes? Or, are you uggesting a kludge workaround (e.g., change the "extension" to something unique; build some middleware that consults a user-maintained table of creator attributes; etc.)?

Cameron Kaiser wrote: Ah, OK. So the OS already has provisions to handle it and hides those details from the user. I.e. it does the things I was insinuating the user would have to do, manually.

----- Original Message ----- From: "Cameron Kaiser" <spectre at floodgap.comTo: <cctalk at classiccmp.orgSent: Monday, August 28, 2006 6:30 PM Subject: Re: "File types" is everything. On a FAT volume the fork gets stripped away, so taking the file and putting it back on the Mac without the resource fork the Mac OS will not know what to do with it (ruins the file).

On 8/28/2006 at 4:08 PM Don wrote: If I understand you... Unix was the first system that I'd ever seen where the file name implied a type. There are very old systems that differentiate between 'data" and "executable" files outside of the file name; it can be via attribute or "type" not part of the file. Unix is one such system--you can have a "Can't read or write, only execute" file. Cheers, Chuck

On 8/28/2006 at 4:47 PM Don wrote: Are you asking, "Did any system keep file type information out of the file name?" The answer is "yes, several did". Here's part of a microcomputer floppy directory from a circa 1977 OS. Note that fiile dates show this disk was probably created around 1986 (yes, it's all in ASCII--no binary fields here): A$DIRECTORY 000000001500000016 SF 064032386 ACONFIG.SYS 000160001610000016 DV 000010199 AMT.PARTS 000170001702700017 DV 000010199 ADX85M26D03 000180004643600046 LV 000080483 AISAM.SYS 000470005814400058 SV 000080483 A$AUTOSTART 000620006201300062 PV 000080483 ARUN 000630009348700093 SV 000080483 AMTMENU 001120013036800130 OV 000010199 ALOCATE 001310014242700142 OV 000010199 A$SBA.C 001430014400000143 II 003 A$SBA.C@ 001450014800000145 MF 055 First column is the file name, the second is the file allocation and length information. The third column is the file type and the record type. S=System D=data, L=boot loader, P=profile, O=binary object, I=ISAM index, M=ISAM data (there are other types). The second characters is the type of record F=fixed, V=variable, I=index. The fourth column is the record length and the creation date. By convention, ISAM index files take the name of the data file, with an "at" sign appended, though there was no particular system requirement for this. If you enter the name of a file that didn't have the O file type, the system won't execute it. Similarly, you can't open a file with anything other than the DV attributes for text display or editing. ISAM files are handled by the ISAM manager and nothing else. You can't do ANYTHING with S or L type files, not read them, not write them directly. I've seen other systems from the 70's with this kind of directory information. However, the idea of a file extension for certain types of files was contagious--note the CONFIG.SYS (well in advance of MS-DOS). Cheers, Chuck

On 8/28/2006 at 8:04 PM Don wrote: Unix, ISIS, CP/M MS-DOS...all have been more popular than the other alternatives, and they strongly influence thinking. As far as I can tell, we're still in a state of devolution. I can go you one better and ask why is there no system record management facility that standardizes file structure? Heaven knows, mainframes had such a notion. But "modern" (read: microcomputer) operating systems tread files as amorphous blobs. You want to structure a file some way, it's up to you and no business of the operating system--that, aside from certain program file structures doesn't care. A binary file displays garbage in a text editor? Who cares? The operating system certainly didn't tell you that "you don't want to do that". One sees this in data conversion frequently. You have a file, generated by some long-forgotten application with no obvious structure--just lots of bits. Now, figure out what it means.... Cheers, Chuck

Andy Holt wrote: IMO, a file *is* an untyped string of *bytes*. The OS shouldn't care about it's representation (none of this "text mode" vs. "binary mode" crap). It's "attributes" should solely be things like size, creation time, ACLs, etc. As the **OS** sees it. The nonsense of "file types" belongs at a higher layer. E.g., IMO the Windows/MAC/etc. GUI's are (read that as: "should be") viewed/built as layers ON TOP OF the OS (from a conceptual standpoint; implementation details may differ). So, if that "presentation" layer wants to *impose* something like a "file type", *it* assumes the cost of maintaining that information and encoding it in some "sensible" manner. [i.e. my issue here is why this encoding seems to have gravitated into the file NAME instead of some other mechanism] IMO, this was a mistake. It forces the OS to know too much about the applications that run on it -- instead of being a resource manager. I.e. it should implement mechanisms, not policy. Exactly. Or, any "unforeseen" file types...

[thread forked as this line is really not what *I* am trying to pursue... :< ] Andy Holt wrote: Sorry, if my choice of the word "bytes" was a distraction. Call them "storage units". I dislike the term "characters" as it tends to imply additional semantics that many files don't follow (or, should we have "Characters" and "characters"? :> ) Sure. But what role should the OS play in that (as pertaining to applying/enforcing structure on *files* within the filesystems that it maintains)? Where does the boundary between application and OS lie? If the OS promotes these lower level structures to a more visible interface (enforcement), then what happens to the application when the underlying hardware is changed? Does it suddenly need to know about some new scheme -- that may not have been in existence when the application was originally crafted? E.g., I can understand a database indexed using Btrees later converted to use a different scheme -- the DBMS handles this. If the DBMS wants to exploit features of the underlying hardware (e.g., tablespaces to disperse among multiple spindles), then it can do so. Because these things are important to *it*. I just don't think this belongs *in* the OS (if the OS wants to keep a descriptor ACCESSIBLE BY APPLICATIONS that allow those applications to adapt their strategies to those aspects portrayed in that descriptor, that makes perfect sense). I include this sort of support in my systems. "Little things" like cache size, MMU page size, etc. -- so my code can adapt to changes in the underlying hardware without major rewrites. (e.g., I process audio in page size chunks so I can move those chunks quickly between processes -- if the page size changes, it is a big efficiency hit/gain for me so I want to know about it and react accordingly). Yes. But, my point is, the *application* should be responsible for handling this. I don't want the OS to arbitrarily decide: "this is a text file represented in USASCII -- I will automatically convert it to UTF-16 for this application...". There are far too many cases where conversions/coercions can't be done unambiguously. LEave those policy decisions to the application writers (or library designers). Sure. I pack eight 5 bit characters into a five byte struct to save bits. But, *I* do that -- not the OS. If you want to deal with "memory" (disk) as 87 byte records, then use setbuf(), et al. and hope the folks who wrote the library did so FOR THAT MACHINE in such a way as to take advantage of the fact that the underlying hardware uses 87 byte records. You don't have to *only* present the abstraction. As I said, you can augment that with information about the hardware in an auxillary structure. A structure that a program *can* choose to examine to impact it's performance -- but that it can also choose to *ignore* withOUT peril! The technology is still applicable (and still used in RDBMS's). But, you will note that systems that rely on/exploit these things are tied more intimately to their underlying implementations. E.g., a change in the OS's filesystem implementation can render "good designs" suboptimal. If done well, the application can be tweeked to recover some/all of that original performance. That's *exactly* my point! GCC *should* vomit. It shouldn't expect the OS to magically convert that Unicode file into ASCII (what does UTF+2836 map to? '('? ')'? '['??). Instead, if *it* (GCC) can handle Unicode, it should. Otherwise it should choke (gracefully). I wouldn't expect an aria when an arbitrary .gz file is fed to a .wav file player! :> (sigh) But, none of this answers the query of "Why file type information has migrated into the file name"... :> (persistent, eh? :>) To me, having "something" (IMO, *above* the filesystem) that tracks the "type" of a file -- for the benefit of users *of* that file -- is a desireable adjunct *to* the OS. [though, having made these arguments, I am building support for that mechanism *within* my OS -- since it is a key service that all apps *must* use, in my case :< ]

Andy Holt wrote: Note my point that the OS shouldn't *care* (IMHO) about the type. E.g., nowadays, this information is typically used by The Desktop. So, why can't The Desktop assume responsibility for maintaining it? Using whatever mechanisms *it* deems efficient. Hmm.. I was unaware that NT did this. I thought it just embellished the ACL's, etc. As I have stated previously, "collecting" is not my interest. Rather, I see older machines as "lost ideas". Some ideas probably *should* have been lost (e.g., Harvard architecture, non-binary radixes, etc.) but others appear to have been *unfortunately* lost. My point in starting this thread was to decide which category this idea falls into :-/ Exactly! Given another 10 years, we'll return, once again, to the "mainframe with terminals" model that the industry revisits almost as regularly as the four seasons! (though the role of The Mainframe will now be played by The Internet) Maybe it *is*!! ;-)

I don't know if anybody pointed it out already but the IBM S/38, AS/400 and derivatives have strongly typed 'objects', not files. It doesn't matter what you name a database table, an Ethernet line description, or a user profile - the OS knows what those things are and will not interpret them differently if you copy or rename them. As a concession to hierarchical filesystems like the ones used by Unix there is a 'file system' where the OS refuses to interpret what the files are and just considers them streams of bytes.

Don wrote: The applications use OS services to create the objects. There are APIs for creating all of the different types of objects on the system, and the OS handles the tagging. Keep in mind that OS/400 (or whatever the current name is) has a fairly limited set of objects. The job queues, user profiles, subsystem descriptions, database tables, etc. are all 'objects'. Things like generic files that are not interesting to the machine but might be interesting to client machines that connect to OS/400 get dumped in generic 'stream files' in a hierarchical filesystem. The OS enforces correct usage of these objects. You can read or access a database table as a different type of object. The OS implements this by storing meta data in each object and managing object types in a centralized manner. Mike

Don wrote: OS/400 isn't an OS, it's a way of life. :-) The classic 'objects' that the operating system uses aren't really in a filesystem. It looks vaguely like a file system (a very flat one), but it isn't. An object can be examined by paging in the header area and examining the type bytes embedded at a particular offset. I don't want to clutter the list .. to read further search for 'single level store' and AS/400 and that will give you the idea. Mike

der Mouse wrote: Yes, but this is an artificial distinction. Main memory is still homogenous to the CPU/programmer. [snip] Sorry, I wasn;t clear in my original comment. What I meant was "non binary -- 8421 -- encodings". E.g., gray code (though useful for shaft and other incremental encoders), bi-quinary, 5421, 2-of-5, etc. While some like Chen-Ho and DPD are interesting hacks, I still haven't found them to be particularly *useful* -- from a software standpoint. (though they can have use in specialty applications -- often with specialty hardware and/or protocols). I'll "hold out" on BCD and packed BCD; and will concede that there are times when sign-magnitude can be a win. But, most of the other encodings are just... *icky*! :>

On 8/29/2006 at 8:08 AM Don wrote: <OT> Okay, this is drifiting OT, but I can't let this go by unchallenged. It merely incorporates the nasty business of blocking and formatting records into a standard set of routines. They don't have to be run at the supervisory level, but convention should dictate their use. The beauty is that data interchange among applications gets easier--and you don't have the run-time library for a particular language implementing its own idea of what a file full of ASCII strings is and being compatible with nothing else. Your example of a COBOL program writing source for a FORTRAN program thus works, as long as the COBOL program doesn't use datatypes that are completely unknown to the FORTRAN world (e.g. COMP-3 numbers). Cyber Record Manager (CRM) was introduced into the CDC NOS world sometime during the 70's and it made a big difference in application code. If your program, for example, had to read a tape full of 7000 SCOPE W-type records, you could simply declare the tape (via job control statements) as containing them, instead of having to write a bunch of code to decipher them. And one application's idea of what an ISAM file was is assured to be the same as another's. For the diehards, you can always declare a medium as containing raw bits and wrestle with them in your applicaton code. But for most applications, there's no reason to do this. How many ways are there of representing variable length character strings? And how many have you run into? Off the top of my head, I've seen--on the MS-DOS/Windows platform the following: byte count+data, word count+data, data terminated by 00, data terminated by 0a, data terminated by 0d, data terminated by 1F, and probably a few others that don't occur to me right off. I'm not a big fan of the "implement whatever weird nonstandard file structure you like and hope no one loses the program that created it" school of thought. </OT> Cheers, Chuck

Oop$ -- --------------------------------- personal: http://www.armory.com/~spectre/ --- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- The moon may be smaller than the Earth, but it's farther away. -------------

On Wed, 30 Aug 2006, Chuck Guzis wrote: IIRC, I saw an interview long ago, (maybe when Gary Kildall was the co-host with Jim Warren of Computer Chronicles?), in which Gary APOLOGIZED for that, and said that it had been a temporary kludge, and hadn't originally been meant to be permanent. For their first assignment, I have my assembly language students write a program to display their name AND the price that they paid for the textbook (to force use of function 2, instead of 9). We then use creating their own puts() function to get into jumps, conditional jumps, and loops. -- Grumpy Ol' Fred cisin at xenosoft.com

On Wed, 30 Aug 2006, Roy J. Tellason wrote: Still there in Int 21h function 9! also, fixed length with padding character (FCBs), also, keeping start and end pointers

On Tuesday 29 August 2006 01:01 pm, Chuck Guzis wrote: Well, in general you have two ways: a) Externaly - aka Length terminated Due some way you know how many symbols there are b) Internaly - aka Stop marker A special Symbol or set of symbols marks the end All can be seen as records/structures with the two components. Classic subcategories are a1) Length before the string (structure with two elements) a2) Length in a different place (e.g. some list, or a structure with stringlength and pointer) b1) A dedicated symbol after the last - e.g. x'00, '$', etc. that does not is part of the information b2) A modifier, like using 2^8 as an endmarker - eg. the last symbol has this bit set (or not set) You may form endless variations of these concepts - as many as you got time on your hand, and belive me, the last 50 years gave developers quite some time to invent the world over and over. Gruss H. -- VCF Europa 8.0 am 28/29.April 2007 in Muenchen http://www.vcfe.org/

Well, I would point out that it moved into the name before it moved out of the filesystem. VMS (see my previous note) not only had a fairly rich set of file types in-filesystem, but also had naming conventions to go with them (which in my experience were mostly just conventions, ie, advisory). I don't know why this was. I conjecture that it was done so that the type, or at least a decent approxmation to the type, would be available to a human looking at a directory listing. One could say that this could have been done by printing type information in directory listings, but that misses the point that conceptual file types were not 1:1 with filesystem file types - as a simple example, the filesystem type information for a plain text doc file and a FORTRAN source file might well be exactly the same. I'm not sure I would choose to. If I did, though, a large part of why would be that humans are used to it. :-) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

This puts me in mind of VMS, which had fairly rich file structure. I recall fumbling about with CONVERT /FDL on occasion. It had things like record-based files and even much (most? all?) of what today I'd call ISAM available in the filesystem.... /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

der Mouse wrote: <snip> Some builds of GNU gzip will indeed hurl on a file not named to its taste. Note that I'm *not* disagreeing with you. As far as I'm concerned that behavior breaks all kinds of conventions. But it is a fact. Doc

der Mouse wrote: [I assume at least one of those "types" was intended to be "file extensions" :> ] Correct. Because UNIX (i.e. the *OS*) doesn't have a concept of "file types" (in the sense of this discussion). That concept (to the extent present) is something associated with any desktop *application* running ON TOP OF it. E.g., if KDE wants to introduce a concept of a file type to enable a "click to open (using the "appropriate" viewer for this type!)" mechanism, then KDE has to assume the responsibility for managing file type information. [this fits with my opinion of where the division of labor should lie between app vs. os] But, still, even in these *layered* approaches, the file name has been chosen as the mechanism for conveying type information. It need not have been (though it looks like the EASIEST way of doing so). Again, I see nothing explaining why this evolution occurred (other than "because folks got used to someone's CHEAP implementation). Or, perhaps the behaviour of so many command line apps, over the years, to *assume* "default" suffixes for the types of files on which they operated (to save us the trouble of typing a few extra characters?) evolved into the *inverse* "convenience" -- letting us tell the machine what application we want based solely on the name of the file that we specified (what a perversion! :> ) Imagine the (cough) elegance of being able to type: $ foo.c // to compile foo $ foo.o // to link foo $ foo // to run foo (neglecting the means of actually *writing* foo! :< )

Sean Conner wrote: It was offered "tongue-in-cheek" -- i.e. isn't this what modern GUI's effectively are doing? And, also, to illustrate how ludicrous distilling everything about a file "type" to an N-character "extension" is, in practice. E.g., how do you link foo.o vs. bar.o (since each may require different libraries, etc.) I.e. type needs to be finer grained than silly N *character* file "extensions"... *everyone* wants to be "DOC", or some other pronounceable extension. So, the file types lose their value (e.g., on my W2K box, Matlab and Mathematica both want to use .m -- so, .m files are meaningless to me since I can't recall FROM THE NAME OF THE FILE which application needs to be opened to process the file). MacOS *seems* to have had the right idea (though I have never used it "seriously" to know for sure).

Chuck Guzis wrote: Exactly. I have .DAT files that 3 different applications want to claim as their own. About the only "file type" that I have NOT had problems with is ".dgy" :> It adds no value, IMO. And, only increases the chance that the *wrong*/unexpected application can be invoked without your being aware of it beforehand (I can list dozens of "extensions" on my W2K box that are ambiguous -- several of which invoke the *wrong* application handler. Hopefully, each of these handlers are smart enough to parse the file given to them to determine if it, in fact *is* a valid <XXXX> file before operating on it. So, the type is merely a convenience for The Desktop. And, IMO, a poorly designed/implemented mechanism. :-( (I *really* need to play with MacOS more and see what the "shortcomings" of their scheme is/was -- aside from file portability)

Did anyone mention MacBinary, the sanctioned method for wrapping two-fork Mac OS files in a single file for transmission or storage in a single flat file? Or the way some apps were smart enough to create Mac files as MacBinary when the files were being stored on non-Mac (networked) file systems? Or AppleDouble format, the way they preserved the fork on non-Mac floppies (both MS-DOS and ProDOS)? Did anyone mention the early NT Server's optional Mac compatibility mode that allowed Macs to store forked files on NTFS? Did anyone mention the way some old Mac apps used the resource fork (not the data fork) for storing data, because there were convenient API calls that made it slightly database-like? Did anyone mention the way Windows hides the extension from the user by default? Would it be useful to discuss old OS filesystem metadata, such as the 80-char "comment" field in AmigaDOS? No one mentioned the http://www.formatexchange.com/ project As for file.dmg.hqx and file.tar.gz, did anyone mention the Icelandic naming habit of assigning a child's last name based on the same-gender parent's first name? Annasd?ttir? ?orvaldsd?ttir? Gunnarsson? At 06:10 PM 8/29/2006, Tony Duell wrote: I wonder if there exists a timeline of when certain Unix concepts came into being. 'file' and magic, for example. To me, it shows that it can be valuable to have an automated method of knowing what's in a file, even for believers in streams of bytes. Tomorrow's OSes will be far more like databases of metadata, I think, than inodes for streams of bytes. Easily recognized, preserved and parsed metadata makes all sorts of interesting applications possible. Geotagging. RFID. GUIDs for everything. EXIF in images can be very handy. Yes, it's easy to think of twists and permutations that will make it complex or problematic to preserve metadata as files change and mutate, but I'm sure people will continue to invent new apps to justify it. I've always thought that even having just "genus" and "species" within the metadata for files would go a long way. Three-char file extensions don't tell much. Apple's old notions of type and creator were handy, too. - John

On 8/30/2006 at 11:01 AM Don wrote: I don't know about Macedonian, but many Slavic languages decline the surname as to sex and marital status. And then there's the whole affair of patrynymics... Cheers, Chuck

On 8/29/2006 at 1:46 PM Don wrote: Not just the Desktop, Don. It also works with command lines; e.g., entering the whole name of a file with a .ZIP extension at a command prompt brings up whatever you've registered as your ZIP handler in Win2K. I don't think this is part of Win9x in any shape.

Hi, Don said: I've not found any serious shortcomings and when using other systems I really miss MacOSs file comments field which allows you to attach a short (1k?) comment to a file - it appears in directory list views and is searchable. Very useful. -- Cheers, Stan Barr stanb at dial.pipex.com The future was never like this!

Yes, it works fine. In fact, you can even do that with USR files with ,U, although only USR files that were OPENed and CLOSEd in the usual way. If you try to load, say, a GEOS VLIR file with that syntax, you only get the info block since the usual forward sector pointers are valid only for the first sector. For that matter, you can also SAVE with ,S or ,U. I always conceived as SEQ files as existing just to allow a distinction between textual data and executable binaries, and having only a superficial distinction from PRGs. -- --------------------------------- personal: http://www.armory.com/~spectre/ --- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- From a SeaWorld funeral: a mourning of the sage of aquariums. -- Andy Pafko

I don't believe that resource forks are supported on UFS filesystems. I won't guarentee I'm remembering correctly though. ISTR this is why I went with HFS+. Besides we've already seen today how good my memory is with reguards to creator attributes on Mac OS X. :^) Various solutions like this are used on various OS's. On VMS they're stored in a MSAF$RESOURCES.DIR;1 directory. I forget how CAP and Netatalk do it on Unix. All I know is when I finally move off of OpenVMS 7.3-2 and/or Mac OS 10.3.9, I'm going to have fun cleaning up all of that from my VMS server! Upgrading either of those versions mean that my Mac will no longer be able to use Appletalk to talk to my VMS server. :^( Zane

On Monday 28 August 2006 05:47 pm, Don wrote: It's also predicated on a certain type of interaction, as in what you describe above with the _user_ selecting which one of several files would be dealt with, which I'm not entirely sure is a good thing to build into a filesystem. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

Sean Conner wrote: Excellent! In my case, directories are active objects and the "file system" is really more appropriately called the "name space". Since directories are active, the operations that can be applied to a directory (i.e. that the directory applies to *itself*) can be unconventional. And, the objects that it can "contain" (reference?) can be quite varied. E.g., some objects may be "volatile", others "static", etc. This would be the problem of the "export method". E.g., how does a digital camera copy it's files to your $computer? In the camera, there is no notion of JPEG, TIFF, etc. They are just values from a CCD stored in memory in some convenient order for the hardware to generate and process. Obviously (?), the data isn't represented internally *as* a JPEG *before* image processing is done (e.g., jitter reduction, color compensation, etc.). Rather, JPEG is just "an acceptable way" of exporting the data (rather than some other oddball format that might require the user to run some "converter" on the data prior to use). But, even "text files" have different types. E.g., shell scripts are "different" than "ascii text". (and this is determined by inspecting the file's *contents*, not *name*!) But you're already using 2 - 4 bytes in the inode to track this type! I.e., '.' followed by 1 - 3 (or more) characters of extension. And, for all practical purposes, you are poorly utilizing those 4 bytes! The first conveys no information other than "an extension follows". And, of the 1 - 3 (typical) that follow, you really only see 36^3 different file "types" (i.e. case neutral, and typically only alphanumerics). So, you're storing 46656 data types in a field that could store 4294967296. (i.e. you could use 2 bytes instead of the 4 you are using) But CP/M didn't *do* anything with the file extension (for all practical purposes). I.e. you could have a test file called foo.foo and your text editor would gladly open it. If an *application* wanted to insist on particular file extensions then it could do so -- usually pissing you off in the process ("No, Editor, I am writing an INCLUDE file, I want to name foo.inc *not* foo.doc") This, IMO, is the only "real" reason that file type has migrated into the namespace. It lets everyone avoid the issue of moving files between systems by simply stating that files are *just* bytes -- even if your applications think otherwise. I.e. if your MS machine doesn't know what .HQX means, <shrug>. It still doesn't address the issue raised by an earlier respondant (i.e. tagging files for special treatment on open) but that could be done by fabricating your own file type. This would be worth looking into. Does BeOS run on "special" hardware?

This reminds me of a project I did for Universitetet i Troms? (a university in Norway). One of the things it did was present a directory view of a file - given a plain file foo/bar, you could access things like foo/bar/id and foo/bar/parent and suchlike. A slightly different slant on that and you've got the sort of thing you're talking about. "With difficulty"? :-) Actually, the notion of such an object rapidly leads me into some curious speculation on user interfaces - I'm having trouble coming up with a UI under which it's practical to use such a name. [Whee, something approaching real classic content!] Actually, executables and object files were really the same type; the only difference was that executables (a) normally had their execute bits set and (b) didn't have any undefined external references left. (I'm not sure, but it's also possible that the entry point in the a.out header was another point of difference. It's been too long since I worked with a.out files.) This changed, eventually; first we got different magic numbers to support demand-paged executables and suchlike, then after a while when everyone was experimenting with different object/executable file formats, ELF seems to have largely won out.... File type and file creator - there are actually two of them. By an interesting coincidence, I was just today talking with a friend of mine who's a serious Machead, and he tells me that, while modern Mac OSes support file type and creator fields, they are for compatability; they are not used for much these days. (The notion of forks is another one that's on its way out; practically nothing needs anything other than the data fork - and, interestingly enough, since (Mac) OS 9, a more or less unlimited set of forks has been supported, not just a data fork and a resource fork.) He tells me that if creator information is present, it is used to find the right app for a file, whereas if not, it defaults based on the extension - and the UI has ways to override this, either one-time ("Open With") or by bashing the creator field on the file to make it sticky. Another important difference here is that on Unix, the file "type" field is part of the name, and thus (eg) vacation.jpg and vacation.txt can exist in the same directory on Unix, whereas it is not possible to have "vacation" of type 0x4a504547 and "vacation" of type 0x54455854 in the same folder on a Mac. I'm not sure whether this is an argument either way, but it *is* a difference. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B