"far"?

Anybody able to help me understand the following bit of code?

Code:

---

unsigned char far *screen;

---

It seems like it's initializing a pointer to a character, but the 'far' keyword throws me off.

It's old. As in 16 bit compiler old. It's how you get more than just the 64K memory for your total program, IIRC. You're still limited by data segments of 64K (again, IIRC), but it's basicly so you can use extended memory beyond just the 64K.

It's been obsoleted with the appearance of 32bits (and 64, and 128.. you get the idea).

If you're using a real compiler, you don't need to use 'near' and 'far' any more. Otherwise, Google up 'near' 'far' 'pointers', and you'll get some more info.

Quzah.

Great, thanks guys. Well, quzah at least :p

'Far' actually means that your pointer is addressing a data segment that is not in your current 64k data segment.

A 'Far' jump means you are jumping to code that is not in your segment.

But quzah is right in that it is not used anymore in 32-bit code. It was from the old DOS 16-bit days when you were only allowed 64kb data segments at any one time - but you could have a lot of these segments, they just could not be over 64kb. I can't believe we actually got anything done in that amount of memory.

The 64kb limit comes from the fact that you can only have 0 to 65535 values represented in 16 bits. Data segments in real segmented mode are composed of a segment:offset pair where segment can be any segment in range 0 to 0xFFFF and offset can be in range 0 to 0xFFFF.

So max value is : FFFF:FFFF
This is actually where the BIOS ends. It starts at FFFF:0000. Video memory for low-res 256 color modes starts at A000:0000 and ends at A000:FFFF although all of that is not used.

Code:

---

unsigned char far *ptrToVideo=(unsigned char far *)MK_FP(0xa0000,0);

---

This means that ptrToVideo points to video memory. Since this segment lies outside of our current data segment, you must use the 'far' keyword. It no longer applies.

In old 16 bit code if far is not specified then 'near' or inside of 65535 or within 64kb is implied. A near pointer is one that points to an address within the current segment.

Except in the large and huge memory models (Linker options, how I miss having to tweak thee to get things working... :o), where all pointers are treated as far (Generating larger code). ;)

But most compilers then were not reliable enough to remove the far keyword from your declarations. Many times old Turbo C++ would not run my video programs simply because far was not used, even though I was in the large memory model.

Wow, thanks guys, you really seem to know your stuff. Does anybody hvae any reccomendations about a compiler for 16-bit DOS that I could run in say, XP? Being able to run it in DOS would be fine too since i have a very nice DOS emulator.

Turbo C++ 1.0, 3.0, and/or 4.5 will work just fine under XP. I've tried just about every DOS function on interrupt 21h and most of them work fine. You can also write interrupt handlers, etc.

You may have some difficulty with the following under XP:

1. DMA programming
2. Loading programs into high memory
3. Using upper memory blocks
4. Intercepting hardware interrupts like in the case with a sound card generated interrupt
5. Certain software interrupts having to do with EMM386.EXE and HIMEM.SYS
6. CD-ROM - 2Fh multi-plex interrupt - simply because MSCDEX.EXE and the CD-ROM driver won't be in upper memory.
7. Direct low-level access to the hard disk using BIOS interrupt 13h. Windows locks the volume and I've been unable to unlock it from the interrupt, from int 21h, or from int 2Fh.


The only way to do the above is to actually create an entire DOS session complete with an autoexec.bat and config.sys bootup sequence. Perhaps an emulator can do this but w/o one, you will be unable to be in a totally separate DOS session.