Date: Mon, 7 Oct 1996 17:46:34 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Pieter Kunst <kunst AT natlab DOT research DOT philips DOT com>
Cc: Ronen Friedman <ronenp AT netvision DOT net DOT il>, djgpp AT delorie DOT com
Subject: Re: a problem with CURSES
In-Reply-To: <3259178F.1D37@natlab.research.philips.com>
Message-Id: <Pine.SUN.3.91.961007174030.4486C-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Mon, 7 Oct 1996, Pieter Kunst wrote:

> > The traceback always shows that the problem occured in
> >         _dj_movedata+33
> >         wnoutrefresh+319
> >         wrefresh()+50
> >         from line 29 in the attached program
> 
> The problem occurs when calling 'wrefresh()', i.e. when the
> transfer from the internal PDCurses screen memory buffer to
> the physical screen memory is made. This is done (by PDCurses)
> using a call to 'movedata()' which is the standard method to
> transfer data from protected mode to real-mode DOS memory
> (in this case the text video memory at B800:0000).

I don't think so.  First, `wnoutrefresh' doesn't call `movedata', and
`movedata' doesn't call `_dj_movedata'.  So if the (incomplete) traceback
posted by Ronen is anywhere near the truth, the program crashes when
moving data between two buffers (probably inside `memcpy' call), and not
from a PM buffer to the video memory.

However, without a full traceback, it is impossible to say what exactly 
goes wrong.  For all I know, it might be that the program passes a null 
pointer to `memcpy' and is killed by CWSDPMI's null pointer protection, 
whereby on NT it manages to get away with it.