Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!funic!santra!hila.hut.fi!jmunkki
From: jmunkki@hila.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Memory Protection (was: Gripes)
Message-ID: <1991Jan29.174321.19621@santra.uucp>
Date: 29 Jan 91 17:43:21 GMT
References: <1991Jan25.183443.2825@waikato.ac.nz> <1991Jan25.213652.26781@cbnewsk.att.com> <1991Jan29.074646.7218@actrix.gen.nz>
Sender: news@santra.uucp (Cnews - USENET news system)
Reply-To: jmunkki@hila.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, FINLAND
Lines: 60

In <1991Jan29.074646.7218@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes:
>ned.horvath wrote:
>>The OS proper is the moral 
>>equivalent of floor sweepings, and the ugliness of HFS and MultiFinder
>>are the result.
>
>What's so ugly about HFS?  I don't see any problems with the programming
>interface to it, and it looks to be a pretty good implementation of a
>high-performance file system -- the use of a volume allocation bitmap, and
>file extent and directory b*-trees in particular enable much better
>performance than the schemes in many other operating system (such as
>MS-DOS and Unix, for example).

HFS performs ok, but it has a really nasty progrmming interface. Unless
you are just using SFGetFile and SFPutFile, you need to know about
directory id numbers, working directory reference numbers and all the
garbage that goes with them.

Assume for instance that the user opens a document. To do this, a file
is selected and the program now has a working directory number and a file
name. The program opens, reads and closes the file (no problem here). The user
then edits the file and wants to save. The program still only has the
working directory reference number, which at this time might no longer
be valid. (I might be wrong here, so please correct me. I've never really
understood when and how the numbers are allocated and deallocated. I know
they will not be deallocated, if a file is open, but I think the latest
guidelines say that files should not be left open.)

Another interesting scenario involves copying a file. The only true way
to do it involves opening and reading the resource and data forks and
the finder info. It's a lot of work, if you want to do it reliably.

Of course, the latest file system _might_ support a file copying trap.
This trap of course works only on AppleShare volumes. Apple didn't
bother implementing it on local disks (at least I never got it to
work). Another silly limitation is that you can only copy or move a
file within a single volume.

As long as things are relatively simple, everything is nice and easy.
The IM-II file manager chapter is actually quite readable and can even
be understood with relative ease. The IM-IV file manager chapter documents
zillions of calls, all of which seem to do almost the same thing and
none of which seem to do what I want them to do. Then there is of course
the IM-V documentation for appleshare volumes (you can't skip that, can you?)
and the next Inside Macintosh some some new hacks and kludges installed
to make the programmers life easier (assuming that the progrmmer is happy
to run only with system 7.0).

AppleTalk and the File Manager are the worst parts of programming a Mac.

What I would really like in a file system would the capability of making
a file appear as an area in RAM. I think this has been implemented with
Mach and it would be a very nice addition to any OS. Unfortunately it does
require a MMU, so as long as the Classic Mac is alive, there's no chance
of it getting implemented on the Mac.

   ____________________________________________________________________________
  / Juri Munkki	    /  Helsinki University of Technology   /  Wind  / Project /
 / jmunkki@hut.fi  /  Computing Center Macintosh Support  /  Surf  /  STORM  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~