* Paul Wankadia writes to Rowan_Crowe, on Saturday October 19 1996
   at 11:56:

 R >> Huge pointers are far pointers which are 'normalised' (ie:
 R >> 0xb000:8000 is normalised to 0xb800:0000) before each access to
 R >> avoid segment overwrap, meaning you can address more than 64k
 R >> with them. Due to this

 PW> But isn't 0xB800:0000 the same as 0xB000:8000 -- both turn out to be
 PW> 0xB8000, don't they?

Yes, they're the same linear address. That's one of the quirks of the
segment architecture.

Consider the following code:


/* Compile for real mode DOS */

int main(void) {

    int *p;
    p = 0xFFFF;

    *p = 1;

    return 0;

}


It's bad code because it's writing to non allocated memory, but it's for
demonstration only, and it's going to stuff up your machine or DOS process
anyway. If you run this, it will cause an exception 13 error (assuming you
run it on a 386+). Depending on your OS and memory manager, it may print a
message and have an option to terminate the program, or it may lock up your
computer.

The reason it causes an exception is because you're writing an int (for
real mode DOS, 2 bytes) to the very end of a segment. The low byte gets
written to DS:0xFFFF, but where does the high byte go? There's no such
thing as DS:0x10000 in real mode. Thus the exception.

In huge mode (let's assume DS = 0x1000), 0x1000:FFFF would be converted to
0x1FFF:000F. Low byte in 0x1FFF:000F, high byte in 0x1FFF:0010. No
exception.

This is a pretty useless example, but it does demonstrate how huge pointers work.

 R >> extra conversion overhead, you should only use the huge model if
 R >> you really have to. (In general, very broadly, the smaller the
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 R >> model, the less overhead and memory used).
      ^^^^^^^^^^^^^^^^^^^^^^^^
 PW> I read that far pointers are very slow -- is that true?

I wouldn't say "very slow", but of course they're slower than
near pointers. You choose the memory model that best suits your
application. If it's a 15k utility, then use tiny. If it's a mammoth 4Mb
executable with overlays and lots of memory usage, you'd be using large, or
huge if you had to manipulate more than 64k of data in one segment.

 PW>> I was told (prior to this) that global variables should be cut
 PW>> down as
 R >> Presumably global means a static variable, accessable across
 R >> different

 PW> "Global" as in not local to a function...

OK, I'm a bit lost with some of the C terminology. Are we talking about a
variable that's in scope for several or all functions in the current
module, but not visible to other modules?

 PW>> you haven't already replied about this, what EXACTLY does "extern
 PW>> \"C\"" do and mean???
 R >> The way I understand it, that's just a wrapper for C++... you see
 R >> it a lot in header files:

 R >> void _Cdecl _FARFUNC __assertfail( char _FAR *__msg,

 PW> I presume this _Cdecl does much the same thing?  BTW what do they
 PW> actually do?  I'm guessing they generate special code for calling and
 PW> for variables?

_Cdecl means to use the C calling convention, which means passing
parameters from right to left, and the caller is responsible for cleaning
up the stack. The other common calling convention is Pascal/BASIC:
parameters passed from left to right, and the function cleans up the stack
itself.

Cheers.

---