Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!caip!nike!ucbcad!ucbvax!amdcad!jimb From: jimb@amdcad.UUCP (Jim Budler) Newsgroups: net.micro.mac Subject: Re: Easy of programming, Mac, Amiga Message-ID: <13110@amdcad.UUCP> Date: Tue, 23-Sep-86 01:27:04 EDT Article-I.D.: amdcad.13110 Posted: Tue Sep 23 01:27:04 1986 Date-Received: Tue, 23-Sep-86 06:04:54 EDT References: <8609182058.AA24864@cory.Berkeley.EDU> Reply-To: jimb@amdcad.UUCP (Jim Budler) Organization: AMD, Sunnyvale, California Lines: 83 In article <8609182058.AA24864@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: +--------------- | Foolish person, that is simply the executable format that someone | made up. Object files have the same sort of format. Fonts have different | formats. Some backup programs use a vitual hierarchy format. That has | nothing to do with the MAC's filesystem. Try applying my last example to | the MAC's file format (NOT directory structure... single-file format). You | can't. Unix Files are exactly ONE contiguous stream, period. Certainly the | executable format is similar, in a remote way, to the macs file format, but | the difference is that you are BOUND by the mac's file format for the entire | system, not just the executable. +--------------- Name calling yet. My article did state that the file stucture under Unix appeared as a contiguous bytes. I consider that a limitation, and said so. As I said, a programmer can program entirely in CODE resources, so that no other resources are used. If I can emulate the Unix stdio library, and Unix applications on a Mac by ignoring the dual nature of the file system, except for one bit in my file open calls, how can it be that I am limited by the Mac's file structure? I can have shell interface, place all my data in a contiguous stream in a file, and access my applications internals as contiguous bytes if I chose to. +--------------- | made up. Object files have the same sort of format. +--------------- Yes. Exactly the same. The difference between an executable and an object file is the contents, not the structure. I hope you don't think that a Unix file is all physically contiguous. I was attempting to refute the argument previously stated by someone that the Unix file structure was more normal. The file structures differ only in having two directory entries, pointing to two different starting locations. The *directory* structures differ considerably, but I was trying to point out, provide much similar information. I chose the executable because it is a common file type (not structure) roughly comparable to the macintosh. I could have chosen any pure data file on either, and pointed out their similarities also. They differ only in that the Macintosh pure data file has an extra *entry* in the directory for the resource fork. It may be empty and may be ignored. That data file can be accessed in exactly the same way as an Unix data file, namely fopen(), fget(), fput(), lseek(), fread(), fwrite(). A common programming trick on the mac is to put data in the data fork of an application. This would be like placing /usr/lib/dict/words inside spell(1) on Unix. On unix this cannot be done unless you consider all the data in /usr/lib/dict/words to be static. The program spell would not have to be rewritten for the Mac (except legally) except for the change of the pathname from /usr/lib/dict/words to the program name itself (assuming I'm operating under a shell with in/out redirection). How can something like this be considered a limitation? It enables me to do something that cannot be done under Unix. I could do it the same way as Unix, namely place words in a seperate file in a known location, but then when I copy spell to another disk, I have to copy both of the files. Barring the obvious: multitaking, memory requirements, there are few tasks which can be written for Unix, that cannot be ported as Unix style tasks to the Mac. If you ignore the resource structure of the Mac, do not use multiple fonts, do not use bit mapped graphics (that isn't Unix anyway), treat the tty port as an ascii device driver, treat the printer and modem ports as ascii device drivers, use the default window size the compiler provides, you will get very unixlike applications which will perform like tasks. This, as I said in the other article, is the programmer's CHOICE. It has nothing to do with the file structure. -- Jim Budler X X Advanced Micro Devices, Inc. X X (408) 749-5806 X Usenet: {ucbvax,decwrl,ihnp4}!amdcad!jimb X X Compuserve: 72415,1200 X X Signature, what signature? I'll make my mark!!