Newsgroups:	comp.os.msdos.djgpp
From:	Elliott Oti <oti AT phys DOT uu DOT nl>
Subject:	Re: Redirecting output
Sender:	usenet AT fys DOT ruu DOT nl (News system Tijgertje)
Message-ID:	<Pine.OSF.3.95.980617160056.24644A-100000@ruunat.phys.uu.nl>
In-Reply-To:	<3.0.5.32.19980617223636.007b7d20@pop.uow.edu.au>
Date:	Wed, 17 Jun 1998 14:40:16 GMT
References:	<3 DOT 0 DOT 5 DOT 32 DOT 19980617223636 DOT 007b7d20 AT pop DOT uow DOT edu DOT au>
Mime-Version:	1.0
Organization:	Physics and Astronomy, University of Utrecht, The Netherlands
Lines:	47
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

On Wed, 17 Jun 1998, Brett Porter wrote:

> Hi DJGPP users,
> 
> 	I'm working on a text based project here which uses text windows on
> occasion and shells to other programs.
> 	I was wondering if it is possible to redirect the output of this program
> into the window. The window will probably use the "conio.h" functions to
> define it, but called programs will ignore this using stdout. Even if the
> programs use cprintf, it won't know the calling programs settings will it?
> So how can I do it? I can pass arguments to the program to tell it the
> colours and window to use, but that won't work for programs I haven't written.

Offhand a couple of idea's:

*Redirect the output of the program to a file, and display the contents of
the file once the program has run. Either do this using "foo.exe >
output.txt" or some such command, or look at the sources of redir.exe to
redirect stdout and stderr to a file. Won't work for programs that write
to the screen directly.

*For programs that write directly to video memory at 0xb8000 you might
want to peek at the memory locations there and read the data directly.
Won't work for programs that reset the video mode or clear the screen
before exiting, and you have to make sure your program doesn't reset the
video mode or overwrite the screen before reading from 0xb8000.

*If what you have in mind is ++displaying++ the output of a program
realtime, while it is running, in a window, kind of like a DOS box, that's
a whole different kettle of fish. That involves multitasking: setting up a
TSS for the program to be run, giving it 1 MB of memory in which to run,
hooking up the timer interrupt, and switching between your program's TSS
and the child program's TSS several times a second. You can then
periodically blit the 4KB from the 0xb8000 offset of the child program's 1
MB to your virtual screen (or from 0xa0000 for graphics programs). This is a
difficult project akin to practically building your own OS, so I suspect
that you don't want to do it this way, but in case you do I can give you
links to URLS of people doing similar stuff, and help out with the little
info I have gathered on the subject.

HTH,

  Elliott Oti
  kamer 104, tel (030-253) 2516 (RvG)    
  http://www.fys.ruu.nl/~oti

- Raw text -