Date: Thu, 18 Jun 1998 09:42:13 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Gisle Vanem <giva AT bgnett DOT no>
cc: blp01 AT uow DOT edu DOT au, djgpp AT delorie DOT com
Subject: Re: Redirecting output
In-Reply-To: <199806171451.QAA08532@login-2.eunet.no>
Message-ID: <Pine.SUN.3.91.980618094152.23552A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 17 Jun 1998, Gisle Vanem wrote:

> If the sub-program writes to stdout (or stderr), then the parent program
> can trap all text by installing a handler for real-mode interrupt 29h.
> Allocate a real-mode callback (rmcb) in your program. The RMCB gets called
> for each character written, so it might be a bit slow (switching back and
> forth between real/prot mode).

Not only will this be dirt slow, but it also has a subtle but
significant drawback: the Int 29h handler is called from the DOS code,
so you are in the middle of a DOS call, and the InDOS flag is set.
This means that the program which catches Int 29h cannot call any DOS
functions.  If it does, the machine will crash, because DOS is
non-reentrant.  And since DJGPP programs use virtual memory, the DPMI
server might just call DOS on your behalf if it needs to page in/out
some data or code.

So the only safe way to use this method is to lock everything
(e.g. using _CRT0_FLAG_LOCK_MEMORY) or otherwise disable virtual
memory.  In other words, this is no good for any non-trivial program.

> If the sub-program is written in Borland and is using conio functions
> the RMCB might (?) work provided `directvideo' is false.

No, it won't.  When directvideo is unset, Borland uses BIOS functions,
which are below Int 29h (actually, the default handler for Int 29h
itself calls function 0Eh of the BIOS Int 10h).