Xref: news-dnh.mv.net comp.os.msdos.djgpp:1543
Path: news-dnh.mv.net!mv!news.sprintlink.net!europa.chnt.gtegsc.com!cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!news.sesqui.net!rice!news!sandmann
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: V2 and PDCurses again...
Date: Mon, 14 Aug 1995 10:42:03 CDT
Organization: Rice University, Houston, Texas
Lines: 12
References: <DDABpq DOT 2r6 AT jade DOT mv DOT net> <40n13f$qn7 AT phcoms4 DOT seri DOT philips DOT nl> <DDAuCL DOT 9I4 AT prl DOT philips DOT nl>
Reply-To: sandmann AT clio DOT rice DOT edu
Nntp-Posting-Host: clio.rice.edu
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

> To my best knowledge the _FAR_POINTER macro doesn't use the 0xe00xxxxx type 
> addressing, at least not with DJGPP V1.  (From the stack trace supplied it 
> was clear that some call to dosmemput() was made.)  I've been using PDCurses 
> 2.1 and 2.2 inside Windows DOS boxes for a long time

The problem is that the _FAR_POINTER macro has the + 0xe0000000 hard 
coded, probably from a time before dosmemput and dpmi support.  V1's 
dosmemput had to be able to handle the 0xe.... type addressing so masked
these bits (they were in ScreenPrimary, etc).  So the FAR_POINTER macro
adds "shouldn't be there" bits and dosmemput took them away...
With V2, since the 0xe000 stuff completely removed from the headers, 
this masking was removed, and thus the breakage.