Date: Thu, 1 Jun 1995 19:19:01 +1000 (EST)
From: "Junaid A. Walker" <junaid AT betty DOT eng DOT monash DOT edu DOT AU>
Subject: Re: dpmi DS:VRAM hack
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu, Giva AT bbb DOT no



On Thu, 1 Jun 1995, Eli Zaretskii wrote:

> > Another solution to all these far-memory tricks (and hacks) would be
> > real far-pointers. How difficult would it be to implement this in
> > GCC ? This is a FSF issue I presume, but the djgpp community has lot
> > of pull there.

	Hehe! FSF have repeatedly stated that they have no intrest in
DOS ports of their programs. They come from that bigger than life camp,
that insists that all machines are fat with memory, and CRAYsy with
CPU cycles, and that Unix is all there is (true, but we can phantasize 
about things outside of the unix domain cant we?). 
One almost thinks that the djgpp newsgroup has been sabotaged all this
time....

> 
> What's wrong with the DJGPP farptr functions?  I find them much better
> approach than the much-hated (at least by me) far pointers, because the
> latter pollute the program source in a way which makes porting very
> difficult.  Function call is much cleaner way: you just rewrite a single
> function and roll.  And farptr functions compile to the same 2 machine
> instructions which a compiler would emit for real far pointers, so
> there's no runtime penalty, either.
> 
> But I guess there always be people who can't do without tricks and hacks...
> 

	Segment overides incur 1 clock overhead (is this true on a Pentium?)
Plus idiologically, a pointer is a pointer that points to anything,
and segments are sick (and god gave the 386 a paging unit so why not use 
it?).
	Admittedly for VRAM blitting, you could probably be well justifed
to temporarily load DS,VRAM_selector and be happy. But the holly grail is
not even to do this....just like a file descriptor can point to any 
type of I/O device, so should a pointer be able to point to any type of
memory resource.
	As for DMA in the first meg, well this is not time critical,
so go as slow as you please.
	Lastly transfer buffers in conv. mem. are incapacitated by 
RM-PM switches.

	I think Mr Sandmann is quite right in his aproach that if you
really want the hack, then use it, even support it in the extender/
dpmi server. But the fall back method should be used for compatablility,
and to ensure system integrity. As long as the system is reliable is
the enviornment that you choose, use it. After all that's what
config.sys is for.

	I think that it will be hard to ween people off far pointers,
for 2 decades we've been brainwashed by intel, microsloth and borland
(well borland are the good guys). However the logistics for supporting
far pointers are almost as bad as gas supporting 16-bit, or gcc286,
and all pointer comparison code breaks. You wouldnt wish that on your
worst enemy.

	Junaid