A near pointer is a 16 bit pointer to an object contained in the current segment, be it code segment, data segment, stack segment, or extra segment. The compiler can generate code with a near pointer and does not have to concern itself with segment addressing, so using near pointers is fastest, and generates smallest code. The limitation is that you can only access 64kb of data at a time, because that is the size of a segment - 64kb. A near pointer contains only the 16 bit offset of the object within the currently selected segment.
A far pointer is a 32 bit pointer to an object anywhere in memory. In order to use it, the compiler must allocate a segment register, load it with the segment portion of the pointer, and then reference memory using the offset portion of the pointer relative to the newly loaded segment register. This takes extra instructions and extra time, so it is the slowest and largest method of accessing memory, but it can access memory that is larger than 64kb, sometimes, such as when dealing with video memory, a needful thing. A far pointer contains a 16 bit segment part and a 16 bit offset part. Still, at any one instant of time, without “touching” segment registers, the program only has access to four 64kb chunks, or segments of memory. If there is a 100kb object involved, code will need to be written to consider its segmentation, even with far pointers.
Now, segments overlap. Each segment is 64kb in length, but each one overlaps the next and the prior by 65520 bytes. That means that every address in memory can be addressed by 64kb-1 different combinations of segment:offset pairs. The result is that the total addressible memory was only 1mb, and the total usable memory address space was 500kb to 600kb. That sounds odd, but Intel built it, Microsoft wrote it, and DOS/Windows 3.1 grew up around it. I still have that computer, and it still works just fine, thank you. :-)>
Now the huge pointer. The far pointer suffers because you can not just add one to it and have it point the the next item in memory - you have to consider segment:offset rules, because of the 16 byte offset issue. The huge pointer is a monolithic pointer to some item with a large chunk of memory, and there are no segment:offset boundaries.
Beautiful - huhh?? - well, in order to get that, the pointer to segment:offset calculation has to be done every time you reference the pointer. It does allow you to create and manipulate a single monolithic object that is greater than 64kb, but it has its costs.
On 16-bit operating systems, a huge pointer allows the developer to access a single block of memory that’s larger than 64 kilobytes in size.
normally Pointers are 32 bit length. which are divided as segment and offset.
which are represent as
seg : off 0000:0000 . . . 8000:FFFF. . . . FFFF:FFFF
first 4 hexa digits are segment, last 4 hexa digits are offset
C Program will allocate 64KB (only one segment) memory for data Part (dynamic memory allocation, Local variables).
by using 16 bit we can access that memory thats called near pointer(16 bit pointer).
suppose we need more than 64KB memory to a program / we want to access a particular memory location (in TSR Program)
at the time we neet 32 bit pointer. through 32 bit pointer we can access any segment and offset address.
there are 2 types of 32 bit pointers 1. far pointer. 2. Huge Pointer.
In TSR programming normally we use far Pointer.
The Main Difference between Far and Huge Pointer is
Far pointers are not Normalized. Huge pointers are Normalized.