Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: what to do with the Text Tools (was Re: FasText INIT)
Message-ID: <1991May23.062142.749@nntp-server.caltech.edu>
Date: 23 May 91 06:21:42 GMT
References: <13749@pasteur.Berkeley.EDU> <11434@hub.ucsb.edu> <1991May21.054549.25355@ux1.cso.uiuc.edu> <53187@apple.Apple.COM> <1991May22.025850.9550@ux1.cso.uiuc.edu> <1991May22.095158.23187@nntp-server.caltech.edu> <1991May22.224402.12467@ux1.cso.uiuc.edu>
Organization: California Institute of Technology, Pasadena
Lines: 22

jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) writes:

>You hit the nail quite squarely on the head. ToolBox overhead isn't negligible,
>but GS/OS overhead is not something I want to deal with on a character by
>character basis.

What the?? My idea was that TextTools calls would fill in DWrite or DRead
call blocks and ship the entire string, block, etc., to the device driver
or standard prefix in one shebang so the call overhead is minimized while
retaining the convenience of Tool calls and the speed/flexibility of loaded
drivers (when available) and the standard prefixes.

I suspect you're just pathologically worried about programs explicitly opening
.CONSOLE so your speedy text routines won't have total control of the screen.
I submit you're going to have to deal with this anyway so you're better off
figuring out how to use the .CONSOLE driver to advantage rather than insisting
on replacing it entirely!! Just what is it that you have to do that is so
easily endangered by the console driver? If it's simply screen saving and
restoring for process swaps, I don't see what the problem is.

Todd Whitesel
toddpw @ tybalt.caltech.edu