Date:	Mon, 03 Feb 1997 09:19:26 -0600 (MDT)
From:	Roger Ivie <IVIE AT cc DOT usu DOT edu>
Subject:	Re: [opendos] Accessibility of OpenDOS with braille and speech
	output...
To:	OPENDOS AT MAIL DOT TACOMA DOT NET
Message-id:	<01IEZ2RZJTBC8ZMCGX@cc.usu.edu>
MIME-version:	1.0
Sender:	owner-opendos AT mail DOT tacoma DOT net

> How about doing a little twist like what many drivers do?  After all, when
> you think about it, command.com is a device driver, it's the user
> interface driver.  We should have the option to include a switch, say like
> /fast, which loads a patch automatically over the section of code which
> would normally call the bios.  That would give a 'default' command.com
> which will be speech syn.. friendly, and give those driven for speed an
> outlet to let the pedal down.

One more thought, guys.

COMMAND.COM doesn't actually do BIOS output. It does DOS output. That is, it
writes to a file handle open on the console and reads from a file handle
also open on the console. This does two things:

1)	Makes it possible to run on weird machines like the DEC Rainbow which
	don't have a PC-compatible ROM BIOS.

2)	Makes it possible to (ta da!) redirect the output to a file by simply
	replacing the handle for output by the file name.

If you overhaul COMMAND.COM to do direct screen writes, you still need to
keep all the old I/O code around so that you can

	C:\> dir >booger.out

I've picked dir because it's an internal command; a direct screen-writing
COMMAND.COM can still provide I/O redirection for external commands in the
normal manner. But for the internal commands, it will need to have _two_
versions of the commands lying around so that there's one which can be
redirected.

Unless you're so hot for fast dirs that you're willing to toss output
redirection, that is...

Roger Ivie
ivie AT cc DOT usu DOT edu

- Raw text -