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
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

- Raw text -