Date: Thu, 11 May 2000 15:11:33 -0500 (CDT) From: Adam Majer To: Eli Zaretskii cc: djgpp AT delorie DOT com Subject: Re: __dpmi_paddr and DJGPP pointers In-Reply-To: <200005111328.JAA13167@indy.delorie.com> Message-ID: 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, Eli Zaretskii wrote: > > But I guess DJGPP doesn't suport far pointer... DARN! :) > > That's funny: most people have the opposite complaint: that DJGPP > doesn't support a 100%-flat memory model. > > Perhaps if you describe the situation where you need 48-bit far > pointers, someone could suggest an easier way of achieving the same > goal. I used 100% flat memory model and let me tell you - it SUCKS! It might seem easier but it is awful since no protection exists. You write outside where you are suppose to and well, the best thing is that your program doesn't work (or does :). The worst, loosing entire DIR on a harddrive! :) 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.. 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).. Anyway, I'm just trying to use memory protection to its fullest. For example, I am not using _dos_ds to access VGA ram but two seperate selectors so when I write out of bounds, I know my clipping functions are screwed up! EASY if far * were allows.. A well, nothings perfect. :) Sincerely, Adam