From: mharris AT blackwidow DOT saultc DOT on DOT ca
Date: Tue, 4 Feb 1997 23:26:41 -0500 (EST)
Reply-To: mharris AT blackwidow DOT saultc DOT on DOT ca
To: Roger Ivie <IVIE AT cc DOT usu DOT edu>
cc: OPENDOS AT mail DOT tacoma DOT net
Subject: Re: [opendos] Accessibility of OpenDOS with braille and speech output...
In-Reply-To: <01IEZ2RZJTBC8ZMCGX@cc.usu.edu>
Message-ID: <Pine.LNX.3.95.970204231254.166B-100000@capslock.com>
Organization: Total disorganization.
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

On Mon, 3 Feb 1997, Roger Ivie wrote:
> 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.

DOS is a PC operating system.  Non-compatibles are just that: not
compatible.  Should we make DOS so that it can run on the VIC-20
as well?  It is not PC-compatible either.

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

Yes, so how does writing to the screen effect redirection?

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

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

Here's some pseudo code for you.


...

display_string("blah")
...

display_string(buffer)
{
   if(redirection is taking place)
      write buffer to redirection stream
      return
   
   if(directvideo == yes)
      write buffer to video memory (by calling a direct write
          function, not inline code)
      return
   else
      write buffer to screen via DOS
    
   return   
}

Assuming that all displaying goes through this function (or other
similar functions.  No code duplication is done.  A few
conditions need to be tested, nothing more. redirection has
absolutely nothing whatsoever to do with the displaying method.

I've written MANY programs in which I've allowed the user to
choose between direct writes (using my own video routines) and
DOS or BIOS writes.  Modifying an existing program is pretty
simple as well.  For example, if you use Borland C, you need only
set a single variable to TRUE to enable direct video writes.
That means NO extra code.  This can be done at run time.

Therefore your argument doesn't hold.  I'll send you some source
if you'd like.



Mike A. Harris        |             http://blackwidow.saultc.on.ca/~mharris
Computer Consultant   |    My webpage has moved and my address has changed.
My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html
mailto:mharris AT blackwidow DOT saultc DOT on DOT ca

LINUX: Lost access to your keyboard after a game?  Email me for fix.