Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site Shasta.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!Shasta!gus
From: gus@Shasta.ARPA
Newsgroups: net.micro.mac
Subject: Re: Music Works' Volume Control...
Message-ID: <5398@Shasta.ARPA>
Date: Wed, 15-May-85 13:36:24 EDT
Article-I.D.: Shasta.5398
Posted: Wed May 15 13:36:24 1985
Date-Received: Fri, 17-May-85 03:34:14 EDT
References: <5365@Shasta.ARPA> <658@spuxll.UUCP>
Organization: Stanford University
Lines: 57

> The attitude at least one correspondent takes -- read the volume control out
> on every DA close, or even every systemclick -- is a bit naive.  The nature
> of DAs as "asynchronous processes" makes it impossible to take account of
> EVERYTHING they might do to you.

  No, but it IS possible to take care of the common cases. Only the control
  panel sets the volume control, and then only after a systemclick...

> As a more extreme example, I am working on an application that maintains a
> DeskTop image.  If you run the Extras DA you can delete a file.  Does this
> suggest that I should rescan all volume directories on every system click,
> just in case Extras or something like it removed a file?  Has anybody tried
> doing this to FileVision (which retains 'back to...' in the file menu)?

  I don't know about FileVision, but the finder does just this. The new
  (4.1) finder does it better. It is now perfectly legal for DA's to create
  and destroy files (besides system, finder, and desktop) behind the finder's
  back. How do you think that DA's such as notepad and scrapbook can create
  initial files?
 
> Take a still more extreme example: postulate a DAMover DA.  Such a DA MIGHT
> remove a DA from the System file.  So, I guess I had better reconstruct the
> apple menu on every system click as well.  What have I missed?  An
> irresponsible DA may clobber the System Font or one of my application fonts
> on a system click...

  The key word here is irresponsible. Obviously, a buggy or misfeatured DA 
  will cause problems. It is not unreasonable for DA's to be responsible for
  not mucking around with active resources. A DA mover DA should patch the
  apple menu itself.

> How well will your last program run if some asynchronous process shoots out
> its temp files on the fly?  Or overwrites them?  Do you recalculate
> checksums on everything before you trust the data in the file?

  A delete file DA should not touch open files. All temp files should remain
  open when in use, and should have reasonable names like 'Undofile' If a user
  still manages to delete the file, he's asking for it, but you can do that to
  practically any program on any machine.

> You see the problem.  When is a "user-friendly" system allowed to give up
> in the face of a hostile user?

  In general, you should only expect things to happen that can happen with
  the standard 8 DA's. To this I add two things - Adding a menu in the menu
  bar, and deleting unopened files. (files are already created as mentioned
  above.) Also, you should not store things in strange places such as in free
  blocks of memory, and you should not store private copies of system data
  structures such as menu lists. It is not unreasonable for a DA to go and
  change the DA and font menus from under you if all you did was issue an
  AddResMenu to create them.

  If people would take the time to write applications that are friendly to
  DA's (those with long menu bars aren't) and DA's that are friendly to
  applications, (those that take more than 8K and don't abide by system
  conventions aren't) then many problems would be aleviated.