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

- Raw text -