> From: Andy Ross > > 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.) >
I can remember the pain too :-). Actually it was a limitation of what could be made for hardware at the time (which I think you already know). The 16 bit address register (max 64k value) was a pretty cool step up, and quite a dramatic improvement over the 8 bit especially in micro chips. (As was the 32 later). The addressing scheme was merely a comprimise for what could be done. The orginization of IBM PC Bios layout on the other hand was a design choice based on expectations of what would be possible for the architecture in 1980 vision. And that sure caused some pain! Best, Jim _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d