Message-Id: <4.1.19981125131141.00a41680@hal.nt.tuwien.ac.at>
X-Sender: tony AT dictator DOT nt DOT tuwien DOT ac DOT at
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 25 Nov 1998 13:41:48 +0100
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: Anton Helm <tony AT dictator DOT nt DOT tuwien DOT ac DOT at>
Subject: display (was: Message: Load error: No DPMI memory)
Cc: djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.981125131423.8152K-100000@is>
References: <4 DOT 1 DOT 19981124142252 DOT 00a25e90 AT hal DOT nt DOT tuwien DOT ac DOT at>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: djgpp AT delorie DOT com

At 13:14 25.11.98 +0200, you wrote:
>
checked the <display> v1.90 beta 5 yesterday night.

1) It doesn't show the described memory eating behavior (of v1.89)
   when running under WinNT4.0.

2) It even displays something more or less useful.

3) It has a problem with the mouse driver:
   When running in a dos box it seg-faults when the mouse is moved.
   The mouse driver is demaged permanently, so you cannot use mouse
   in any program running after <display> in the same dos box.
   (this has the strange "advantage" that you can run <display> again
   and don't have to take care about mouse movements)
   Mouse capability is restored when you close the dos box and
   open a new one.

4) It seg-faults on exit (maybe related with the mouse driver problem,
   because the mose driver is gone afterwards.)

5) It seg-faults on some Windows related keys (Alt-Enter, Alt-Tab)
   in text-mode (did'n try it in graphic mode).

6) When <display> is called from annother djgpp_v2 program by a
   system() command, the calling program dies together with the
   seg-fault of <display> (return to dos prompt).
   (Maybe that's expected behvior, I don't know.)
   

So my current procedure is to run it once, move the mouse slightly
(seg-fault, get rid of the mouse driver, who needs it anyway...) and
then run it again, this time for the batch operation I actually want.


Tony