Date: Fri, 12 May 2000 09:17:19 +0500 (MVT)
From: Prashant TR <prashant_tr AT yahoo DOT com>
X-Sender: tr AT vsnl DOT net DOT in
To: Adam Majer <ummajera AT cc DOT UManitoba DOT CA>
cc: djgpp AT delorie DOT com
Subject: Re: __dpmi_paddr and DJGPP pointers
In-Reply-To: <Pine.GS4.4.02A.10005111505130.12531-100000@antares.cc.umanitoba.ca>
Message-ID: <Pine.LNX.4.10.10005120806010.759-100000@vsnl.net.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, 11 May 2000, Adam Majer wrote:

> I need 48 bit far pointers to access hardware memory (video, DMA, ....). I
> have the selectors but I'm stuck with the akward _far* functiosn. Heck,
> all they do is use the fs register to access other memory... Oh well..

Have you tried the __djgpp_nearptr_enable() function. It can do
exactly what you need. Except that protection is not guaranteed and no
selector limits (Selector limit is 4GB). But it's a simple and useful
thing. Check section 17.7 and 18.6 of the FAQ for more info on this.

> It would have been a lot easier to program in DJGPP if you could allocate
> far pointers. As in having a selector with appropriate limits given to you
> by the new command. 
> 
> char far* MyThins = new char[222];
> 
> That way you could test for out of bounds errors! (I know there are only
> 8K worth of local descriptors that's why it would be reserved for far *
> only)..

This has nothing to do with DJGPP. far pointers are not supported by gcc,
so neither does the DJGPP port of gcc. And that's why the
__djgpp_nearptr_* functions are there for us.

Prashant