Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!mp.cs.niu.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: <1991May22.224402.12467@ux1.cso.uiuc.edu>
Date: 22 May 91 22:44:02 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>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 53

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

>Here's an idea (directed mainly at Dave since he's in a position to forward it
>where it might do some good) about a future direction for the Text Tools.

>Most of us know that the GS/OS team strongly discourages the use of the Text
>Tools, mainly because they are butt-slow and don't like the idea of slot
>arbitration. Yet, Orca (and therefore APW) use them for I/O redirection because
>those programs were written before the standard prefixes and the Console driver
>were available, as were other text-only apps (of which there aren't too many).
>Also, the Text Tools are extremely convenient compared to GS/OS driver calls.

   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.

>The idea is this: extend the Text Tools to make GS/OS device calls on behalf
>of the application where appropriate -- internal slot 3 would use the standard
>prefix for the device that is being set, and requests for other slots would
>search the device list for loaded drivers claiming the requested slot. If only
>a generated driver (or no driver) is available, then the firmware is used.

>This is an extension on the concept behind the MIDI Toolset, and it would solve
>a lot of problems for Orca/APW EXEs -- I/O redirection for PD shells would be
>trivial and backwards compatible, and since the console driver is nice and fast
>we wouldn't need the FasText init any more.

   I agree with the points about slot arbitration, etc, in regards to the Text
Tools.  But what I don't understand is why something like FasText isn't already
a standard part of the system.  It's trivial to implement, and completely
unobtrusive.

   I have a bit of a philosophical problem with the console driver- it's pretty
darn high level to be a device driver.  I'll have no complaints if a way to
patch out the lowest level I/O routines is available- otherwise I'll have the
heinous task of reproducing the functionality of the console driver. NOT 
something I particularly care to do.
   Apple's big thing over the years has been expandability and ease of
enhancement- that ideal seems to have been forgotten in the design of the
console driver.
   Now, if I'm missing something here (i.e. if there IS a way to change low-level
I/O in the Console Driver) punish me like I deserve. But until then, I
stand by my original assertion that Westerfield's use of the Console Driver
in his utilities will be bad for our project. 
(BTW, stupid annoying Illinois Bell blew up my phone. "We'll send someone
out sometime between today and tomorrow to fix it" doesn't allow me to talk
to Mike.) 

--
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! :-)