Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!kuhub.cc.ukans.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!jb10320
From: jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar)
Newsgroups: comp.sys.apple2
Subject: Re: what to do with the Text Tools (was Re: FasText INIT)
Message-ID: <1991May23.192042.18199@ux1.cso.uiuc.edu>
Date: 23 May 91 19:20: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>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 37

toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes:

>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.

  That's reasonable.  I was evidently rambling... but still doesn't fix my
problem.

>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.

  I'm not concerned about output. I'm concerned about input.  Let's say,
we have lots of programs running.  Program A is unbinsciing a file (just
for example), and Program B is doing some user interface stuff.  Program
B makes a call to the Console Driver.  All other processes stop, because
we have to turn off task switching during GS/OS calls (becuase we don't know
which calls are reentrant, and which are not- I suspect none of them are).
So while the user is fiddling 'round with input, he's not getting any work
done. Sort of the antithesis of what we're trying to accomplish.
  I don't hold convictions trivially.
  And I didn't say I wanted to replace it- I said (in my latest word on the
subject) that I'd like a way to patch the lowest level I/O so I can have a
bit of control over this.

--
Jawaid Bazyar               |  "Twenty seven faces- with their eyes turned to
Graduated!/Comp Engineering |    the sky. I have got a camera, and an airtight
bazyar@cs.uiuc.edu          |     alibi.."
   Apple II Forever!        |  I need a job... Be privileged to pay me! :-)