Microsoft C recognizes these non-standard keywords; when applied to an object pointer or a
function pointer, they override the memory model for that particular pointer only.
near (^) A 16-bit pointer
far (^) A 32-bit pointer, but the object pointed to must be all in one segment (no
object may be larger than 64 K), i.e., once you load the segment register
you can address all of the object from it.
huge (^) A 32-bit pointer, and the restriction about all being in one segment is
lifted.
Example: char huge * banana;
Note that these keywords modify the item immediately to their right, in contrast to the
const and volatile type qualifiers which modify the pointer immediately to their left.
In addition to the defaults, you can always explicitly declare near, far, and huge pointers in
any model. Huge pointers always do comparisons and pointer arithmetic based on canonical
[1] values. In canonical form, a pointer offset is always in the range 0 to 15. If two pointers
are in canonical form, then an unsigned long comparison will produce accurate results.
It is difficult and error-prone to compile the interaction between array and struct sizes,
pointer sizes, memory models, and 80x86 hardware operating modes.
[1] We know, we know. We're using "canonical" in the canonical way.
As the spreadsheets and word processors gradually proved themselves, they placed ever-increasing
demands on memory. People have devoted a tremendous amount of energy to coping with the limited
address space of the IBM PC. A variety of memory expanders and extenders have been produced, but
there is no satisfactory portable solution. MS-DOS 1.0 was essentially a port of CP/M to 8086. All
later versions retained compatibility with the earliest one. This is why DOS 6.0 is still single-tasking
and still uses the "real-address" (8086-compatible) mode of an 80x86, thus maintaining the limits on
user program address space. The 8086 memory model has other undesirable effects. Every program
that runs on MS-DOS runs with unlimited privilege, permitting easy attacks by virus software. PC
viruses would be almost unknown if MS-DOS used the memory and task protection hardware built
into every Intel x86 processor from the 80286 onwards.
Virtual Memory
If it's there and you can see it—it's real
If it's not there and you can see it—it's virtual
If it's there and you can't see it—it's transparent
If it's not there and you can't see it—you erased it!
—IBM poster explaining virtual memory, circa 1978