🚀 go-pugleaf

I think this problem could be solved quite simply by using one of the reserved
fields in the GEMDOS executable program header.  One of these fields could be
used for telling the OS that it does not have to clear the TPA before executing
the program.  This should not be a magic number, as there may be other features
that programs will selectivly enable in the future, but at least two disjoint
nybbles should be set aside to have a magic pattern that distinguishes the
value from random garbage.  This would be downward compatible as the older
versions of TOS ignore this field anyway and the programs that set it would
not be depending on the clear not being performed.  Commercial programs could
have this field set up if they don't need the memory to be cleared.

For extended functionality, programs that required that functionality could
have a different initial magic number (hence a different header size) which
would flag to the system that this program used this functionality.  Older
versions of TOS would not load these programs.

A third class of programs would use extended functionality only when it was
available.  A capabilities report could be added into the GEMDOS functions
and these programs would have the old magic number but possibly set some
of the flags in the same field that holds the "no-clear" flag.

As to the memory management scheme for eliminating the OSPOOL problems --
there are better schemes for doing it which don't break programs that make
stupid assumptions about memory ownership and contiguity.  Maybe another
flag?

Yes, operating systems CAN be improved and extended without breaking a
significant number of applications, even when the OS is GEMDOS!

Note:	I left Mark Williams Company's employ in early May and moved to
	Madison, WI.  I have not found a USEnet site that is willing to
	give me an account up here yet, so I'm off the news for a while.
	I occasionally call into Chicago to read my usenet mail, but this
	only happens about once a month for now.  If anyone wants to
	reach me for questions or to yell at me for what I've just said,
	please call me at (608)273-8476 (nights) or write to me at
	1022 D Sunnyvale Ln., Madison, WI 53713.

Note to A.Pratt (or anybody else) at Atari:
	Call me if you still have questions about the MWC 3.0 symbol
	table.  Also, since I'm a registered developer in my own right
	(not just through MWC) is it possible for me to get a beta set
	of the new ROMs?

					Daniel A. Glasser
-- 
		Daniel A. Glasser	dag@chinet.UUCP
    One of those things that goes "BUMP!!! (ouch!)" in the night.
    Alternate address -- CIS: 76505,1672 (if you must.)