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: what to do with the Text Tools (was Re: FasText INIT)
Message-ID: <1991May22.095158.23187@nntp-server.caltech.edu>
Date: 22 May 91 09:51:58 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>
Organization: California Institute of Technology, Pasadena
Lines: 23

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.

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.

Todd Whitesel
toddpw @ tybalt.caltech.edu