🚀 go-pugleaf

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!!