Andy Ross wrote:

> Vivian Meazza wrote:
> > I have the same problem with Main/renderer.cxx. Your solution (or
> > one very like it) solves the problem. I guess near/far are reserved
> > words in Cygwin?
> Goodness, that brings back memories.  The near and far keywords are
> holdovers from 16 bit DOS compilers.  They are still defined (as
> noops) for compatibility with ancient code.
> Basically, the 8086 had 16 bit registers, so a single instruction
> could only address memory within a 64k range (which was defined by the
> appropriate segment register).  This 16 bit object was called a "near"
> pointer.  If you wanted to see things outside that range, you needed
> to use multiple instructions to first load a segment register and then
> execute the load.
> (This really wasn't so insane if you think about it -- the original
> idea for a typical was that all the code would go in a 64k segment,
> the heap data in another and the stack in a third; this 192k address
> space was larger than that available to Unix programs running on a
> PDP-11, for instance.  It seemed like a good solution at the time.  It
> didn't become a problem until typical interactive PC applications
> started needed hundreds of kilobytes of address space.  For 1976, it
> was actually pretty elegant.)
> In C, this notion was implemented by using a "far" pointer -- a 32 bit
> object consisting of both a segment value and a pointer.  The compiler
> would know which instruction sequence to used based on the "type" of
> the pointer it was using.
> Anyway, yes: "near" and "far" aren't portably useful as variable names
> if you want to compile on windows.  I'm sure the MSVC headers have the
> same problem that the cygwin one does.

I'm amazed that you can remember all that! And so long ago! Very interesting
explanation. Thanks.



Flightgear-devel mailing list

Reply via email to