Date: Wed, 24 Sep 1997 00:14:32 -0700 (MST)
From: firewind <firewind AT metroid DOT dyn DOT ml DOT org>
To: Brett Porter <bporter AT rabble DOT uow DOT edu DOT au>
cc: DJGPP <djgpp AT delorie DOT com>
Subject: Re: (pas d'objet)
In-Reply-To: <199709240607.QAA12770@rabble.uow.edu.au>
Message-ID: <Pine.LNX.3.95.970924001033.664A-100000@metroid.dyn.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 24 Sep 1997, Brett Porter wrote:

> > [farptr inline code snipped]

> > Personally, that's total Greek to me. :)  Can any guru in this area give
> > some insight into how\why the far pointer functions work? 
> 
> Well, I'm not a guru but I'll give it a shot :) This is allowed to work
> because you use a valid selector (allocated by your program or the djgpp
> internals) to access memory. Effectivly this inline assembly sets fs to the
> selector and stores the byte at the given offset.

Ahhh, I see. Okay. Thanks for clearing up what was to me one of the Great
Mysteries of the Universe(tm). :)

<snips>

> Why shouldn't they be used? Plenty of applications need a way to get at the
> video directly or the keyboard, etc.

Well, if we wanted an environment where 'far' and 'near' pointer usage is
encouraged, we wouldn't be using the protected mode of DJGPP, would we?

I agree, they can (and -should-) be used in some cases. What I meant (and
obviously didn't express adequately :) was that they should be used
sparingly, like, when there is absolutely no alternative.

> I hear them too, mostly at 2:00am when I am still coding on my game, rather
> than doing my uni. work ;)

Hehe. :)

late\fw