Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!astroatc!nicmad!madnix!jason
From: jason@madnix.UUCP (Jason Blochowiak)
Newsgroups: comp.sys.apple
Subject: Re: deleting DA's from memory
Keywords: DA, CDA, NDA, Desk Accessories, System Software
Message-ID: <690@madnix.UUCP>
Date: 15 Jun 89 05:42:12 GMT
References: <8905272100.AA01113@obsolete.UUCP> <31983@apple.Apple.COM> <678@madnix.UUCP> <32347@apple.Apple.COM>
Reply-To: jason@madnix.UUCP (Jason Blochowiak)
Organization: ARP Software, Madison, WI
Lines: 81


	Pardon any typos, etc., in this article - the editor is being flaky.

In article <32347@apple.Apple.COM> dlyons@Apple.COM (David Lyons) writes:
>In article <678@madnix.UUCP> jason@madnix.UUCP (Jason Blochowiak) writes:
>>How about something like: If the first word that's pointed to by both
>>the CDA Entry and ShutDown addresses in the CDA header is $0000, then the CDA
>>is considered removeable. Perhaps something similar for the NDAs.
> Having the old systems execute BRK
>instructions for new DAs wouldn't be terribly reasonable. :-)  (The *new*
>system could check for the $0000, but the old systems can't be changed to
>do that.)
	Picky, picky :) Ok, then how about this:

Header	data

	str	'I be a better new kind of CDA'
	dc	i4'CDAEntry,CDAShutdown'

	end

NewHeader data

	dc	i'3'			;# of supported new calls
	dc	i4'RemoveThySelf'	;A new call
	dc	i4'0'		;A new call that isn't really supported
	dc	i4'SomeOtherCall'	;Another new call that's supported

	end

CDAEntry start
	bra	really
	dc	i'0'
	dc	i4'NewHeader'
really	anop
* Entry code for CDA
	rtl

	end

CDAShutdown start
	bra	really
	dc	i'0'
	dc	i4'NewHeader'
really	anop
* Shutdown code for CDA
	rtl

	end

	I suppose that it'd only be necessary to have the bra, 0, and ptr to
the new header right after whatever is pointed to in the first pointer in the
header (CDAEntry in this case). Considering the structure of the header is
rather fragile already, I guess that the redundancy wouldn't "robustify" it
enough to make a difference.

>I personally think that sounds like a nifty idea--but any new standards for
>DA formats would have to be compatible with the existing formats and would
>have to come from the appropriate group within Apple.
	Ok, well condition #1 is satisfied, but there isn't much that I can
do about #2 :) The reason I posted my first response (as well as this one)
is so that if other people have comments about my comments they can say so...
I'd appreciate it if you'd forward this (assuming the system design folks
don't read comp.sys.apple) to the necessary people.
	As a tangent - there's one thing (and pretty much only one thing)
that I like about GEM on the Atari ST: The messaging architecture. If things
were set up like that, this wouldn't be a problem, as new message types
could be added. If an application or DA were unable to comprehend a message,
it could say so and that would be that... I like quite a bit of the gs'
architecture, but it seems that quite often the system software isn't set up
in a particularly expandable fashion, even when there wouldn't be much (if
any) performance degradation. Anyways, my feet are getting soapy :)

> --Dave Lyons, Apple Computer, Inc.          |   DAL Systems


-- 
--------8<------------------------------------------------------------8<--------
				jason@madnix.UUCP
	"I am opposed 180 degrees" - George Bush, master mixer of metaphors.
	 	    (Is the IInix mailing group still out there?)