Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!styx!twg-ap!amdahl!amdcad!jimb From: jimb@amdcad.UUCP (Jim Budler) Newsgroups: net.micro.mac Subject: Re: Easy of programming, Mac, Amiga Message-ID: <13054@amdcad.UUCP> Date: Thu, 18-Sep-86 03:07:53 EDT Article-I.D.: amdcad.13054 Posted: Thu Sep 18 03:07:53 1986 Date-Received: Fri, 19-Sep-86 22:49:24 EDT References: <8609170125.AA12047@cory.Berkeley.EDU> Reply-To: jimb@amdcad.UUCP (Jim Budler) Organization: AMD, Sunnyvale, California Lines: 115 In article <8609170125.AA12047@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >>jimb@amdcad.UUCP (Jim Budler) Writes: >>Normal file system? Did you ever notice that in unix applications there >>are two 'forks' called text and data. The difference is that the >>address of the two 'forks' is contained in the file itself, and on the mac >>the addresses are in the directory. > > What are you talking about? > > -Matt Try the command `size /bin/*sh' sometime. This will display something like: text data bss dec hex 65536 2048 19836 87420 1557c /bin/csh 18432 3072 16844 38348 95cc /bin/sh The command `ls -l /bin/sh' gives: -rwxr-xr-x 1 root 68608 Jul 10 1983 /bin/csh -rwxr-xr-x 1 root 22528 Jul 10 1983 /bin/sh As you'll note, text + data is approx. file size. bss is `buffered storage space'. This is preallocated space. The program will take a minimum of text + data + bss memory to run (although paging on a vmunix system can allow programs totaling more than physical memory, echh!) My point is that Unix systems store the file with one directory entry, then within an application, the first portion of the file ( the a.out header) defines where the text and data portions begin. On a mac there are two directory entries, one for the data fork, one for the resource fork. The application `size' gets the information above from the file, using the structure defined in or (depending on your version of UNIX). Diskinfo, on a Mac, gets the some of the same information from the directory. The Mac extended the concept a bit by having the two sections (forks) for non-applications. Is one or the other `normal'? Is one or the other `antiquated'? Is one or the other `better'? Is one or the other `newer'? The adjective `normal' as applied to the Unix file structure was what I was trying to oppose. I was not trying to say that they were exactly similar. The advantage of the Unix system? A simpler directory structure? I doubt it. The Unix directory structure is far more complex than the Macintosh directory structure. It contains a pointer to the inode describing the physical location of the beginning of the file. It contains information about modification date of the file, access date of the file, and size of the file. The inode structure is the real heart of the Unix file structure, and nothing the Mac has approaches it. The advantage of the Macintosh system? The directory structure contains two things the Unix structure does not: The creation date of a file. The starting address of TWO sections. Roughly, and I mean roughly, equivalent to the text and data segments of a Unix application. It lacks: The inode structure, which can tell you when a particular physical segment of a file is modified (I believe dump uses this rather than the directory entry to determine what needs to be backed up). File tags on a Mac don't approach this, especially since they are relatively unsupported. It gains: The ability to modify one portion of the file (i.e. Redit and Resedit) without disturbing the other. You cannot expand any portion of a Unix application without recompiling. With `adb'(sdb,dbx) you can shorten some things (strings) and modify others, but not expand, without recompiling. The creation date. The finder copies a file, maintaining this date. The newer versions of binhex and related terminal programs maintain this date. It is useful. As to the actual comparison between the Unix text+data and Mac rsrc+data? Depends on the programmer. If he programs entirely Unix style, all information in the code, no resources, then his CODE resource is equal to Unix text + data. And his resource fork may contain nothing but CODE ID=0 and CODE ID=1. His data fork will be empty. If he programs Mac style, with resources, then his CODE resources are approx. equal to Unix text + part of the data, and the rest of the resources + the data fork may equal the rest of the Unix data. Most Mac applications do not use their own data fork, but some store static data there. Unix applications store all of their static data in their data segment. I think a comparison should be on the merits, not on the appearance, and certainly not on the state of `normallcy'. I'm certain I will receive much mail/posting/flames telling me how wrong my view of file structures, both Mac and Unix, are. I welcome mail and corrective information. Flames I can do without. -- 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!!