🚀 go-pugleaf

As a followup to Chris Gray's message, what I was thinking of was something
that would work with an MMU without much hassle.  In essence, I was thinking
of an interface library that would for example contain functions such as:

	RegisterMeWithSystem(); /* passes my task id in for resource track */
	NWindowID = AllocateStandardWindow();
	ModifyWindowParm(WindowID, parmValue);
	WindowID = OpenMyWindow(NWindowID);
	/* using the window here */
   cleanup:
	CloseMyWindow(WindowID);
	DumpWindowStructure(WindowID);

   alternate_cleanup:
	UnregisterMe();  /* system closes all my windows and deallocates
			  * anything I got ID's for from kernel process
			  */

[by this method, trying to avoid passing pointers to MMU-protected task-
local memory]

WindowID is an integer you get back from the kernel function that
is actually doing the resource tracking and AllocateStandardWindow gives
you a NewWindow structure, but managed by the system, not by the program.
Then almost all of the interface functions shown in the sample become
some form of message passed to the task that actually owns the chip memory.
Though there is the overhead of the call, there may not be quite as much
need to copy entire data structures through some commonly accessible
memory system.  Each message passed to the kernel process includes
the taskid (from FindTask(0)) so the kernel knows who is doing the asking
and can track resources if appropriate.  Too much overhead?.. maybe.

I have not thought this out very thoroughly, and have not been exposed
too much to other OS's that might use a similar method.  Just thought
I'd output a bit more of the thinking that prompted my original posting.

Rob Peck