🚀 go-pugleaf

In article <2841@well.UUCP>, dwb@well.UUCP (David W. Berry) writes:
> In article <2911@sdcsvax.UCSD.EDU> jww@sdcsvax.UCSD.EDU (Joel West) writes:
> >Somewhere there's a PD program that pre-allocates the alternate screen
> >buffer (so it will be there later) BEFORE other programs steal the
> >memory.
> 	Unfortunately, the way Dark Castle goes about find out if the
> 	alternate screen buffer is available doesn't take that into
> 	account.  Ie., Dark Castle still won't work, even with it
> 	installed.  

I talked to the folks at Silicon Beach over the weekend, and, David
is right, Dark Castles can't tell if you save the buffer for it.
(I was trying to do just that, and couldn't get it to work.)

Actually, this brings up a minor complaint of mine.  Apple starting
encouraging people to allocate space from BufPtr because the system
heap is too small.  This is a terrible hack; there is no management
of this memory, no way to tell why it is allocated or to deallocate
it -- or even a bit to say that the alternate buffers are reserved.

Now that the system heap is larger on the Mac II, and it will break
all the programs that idiotically made assumptions about the value
of ApplZone, maybe the system heap can be expanded on the other machines
as well.  Or maybe we can get some memory management for the BufPtr
area (such as a linked list of allocated areas and a trap to move
down BufPtr).  I mean, this is no better than the hack used to
run DA's on the IBM PC!
-- 
	Joel West
	{ucbvax,ihnp4}!sdcsvax!jww	(ihnp4!gould9!joel once I fix news)
	jww@sdcsvax.ucsd.edu	if you must