Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!hoser.berkeley.edu!bryce
From: bryce@hoser.berkeley.edu (Bryce Nesbitt)
Newsgroups: comp.sys.amiga
Subject: Re: A proposed solution to the resource tracking problem (long)
Message-ID: <3647@zen.berkeley.edu>
Date: Wed, 9-Sep-87 04:39:02 EDT
Article-I.D.: zen.3647
Posted: Wed Sep  9 04:39:02 1987
Date-Received: Thu, 10-Sep-87 07:23:55 EDT
Sender: news@zen.berkeley.edu
Organization: Tubular Transport Devices, Ltd.
Lines: 71

In article <> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>
>COMPATIBILITY:
>	It is impossible to make resource tracking compatible with current
>software...  REASON:  Simply put, many programs rely on resources they haven't 
>closed (memory, interrupts) NOT to be released when they exit.

Good point.  I have written several programs that deliberatly leave
memory allocated after a sucessful exit.  Read on...


>Clearly we must add EXEC calls to allow resources to be kept resident
>on exit.  Current software does not know about these calls so the ABSOLUTE BEST
>we can hope for is to make a standard for NEW software that is written.

Um... Read on...


>CONCLUSION:
>	The end result would be that we would then be able to kill new
>programs which understand the new EXEC calls and still not be able to kill
>old programs which do not.

Argh!!! I think this is a _very_ wrong approach.  You see, it says "Every
last person who _ever_ writes _any_ software must know about this and
use it.  *All* of you, every one.  And, you must do it correctly.". 
Chances of getting everybody to do this are so near zero as to be
uncountable.  Think of all the software now that uses busy waits,
or MOVE SR,<ea> or any other forbidden fruit.
If it's done like that, 5 years from now there will still be untrackable
software that will force people to suffer from reboots, lost resources,
whatever.

A conversion of this magnitude is never easy... but there is a better way.
There is a _much_ smaller base of programmers to target:  People who write
software that must leave resources.

What you do is _well_ before the resource tracking goes in publish a tech
note (to use an Apple-ism) explaining the situation.  Explain that if
you must leave a resource dangling *YOUR PROGRAM WILL BREAK WHEN OS
VX.X IS RELEASED*.  Then describe a check or work arround that will
let your software work now and *AND* in the resource tracked future.

Apple is a company that has done very well at doing the "impossible"
upgrade.  They even switched from the brain-dead "flat" MFS to a
filesystem that actually knows about subdirectories!  I talked with
<name deleted>, a leading Mac software publisher.  They had a software package
in final Q&A.  A tech note came from Apple warning about some future
updates.  They listened and delayed the shipping for one week.  Nearly
a year later Apple released a new system file.  The thing that was
supposed to change did... and because of the last moment change, the
program still worked.  I guess what I'm saying is that this is a tried and
true tactic.

The Intuition LockIBase() call seems like a good example.  It was
in V1.1 but was just a stub.  In V1.2 jimm added some code to go
with it.  The ultimate in structured programming... not only was
it documented before it was written, but people were using it! :-)
:-) :-)


> libraries and devices.

Libraries and devices may need to help in the resource tracking.  What
can be done to let old ones run may become a problem.


|\ /|  . Ack! (NAK, EOT, SOH)
{O o} . 
 (")	bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce
  U