Xref: news2.mv.net comp.os.msdos.djgpp:3994
From: malcolm AT manawatu DOT gen DOT nz (Malcolm Taylor)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: 0xa0000 and dpmi_segment_to_descriptor
Date: Sat, 18 May 1996 20:40:17 GMT
Organization: Grafik Software
Lines: 22
Message-ID: <4nlg9p$u4v@news.manawatu.gen.nz>
References: <3198B45B DOT 316C AT eelab DOT newpaltz DOT edu>
Reply-To: malcolm AT manawatu DOT gen DOT nz
NNTP-Posting-Host: malcolm.manawatu.gen.nz
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

John Fortin <fortin44 AT eelab DOT newpaltz DOT edu> wrote:

>I've been reading the docs, info, and DPMI specs. I also have read the 
>mail archives in order to understand why we must use near or far pointers
>to gain access to the video buffer.  

>I don't understand why we can't use a function such as 
>dpmi_segment_to_descriptor to map this to a linear address without
>the disadvantages of the 'fat ds' method.  What am I missing here??
>This is supposed to give a 64k block, which is just the size of the 
>buffer in memory. 

You can do this, but to access the selector you must use the farptr
functions (far pointers) in sys/farptr.h or assembly. For some
applications the near pointers with their fat ds are faster.
Personally I don't like the idea of loosing protection and the reduced
compatibility that come with that, and I find the farptr functions to
be perfectly fast anyway.

Malcolm