Re: equivalent to far in linux/unix

From: Martin Blume (mblume_at_socha.net)
Date: 08/28/04 

Date: Sat, 28 Aug 2004 13:26:17 +0200

"Andrew Falanga" schrieb
>
> I asked in comp.os.msdos.programmer what on earth far is.
> Actually, found out that one can be near, far and huge; all
> depends on where one wants to put their data.
>

I have to grab this out from the crusted depths of my memory,
so what I say may not be entirely accurate.

NEAR, FAR and HUGE have to do with the memory model of DOS
(remember, this was when somebody said "640 kB will be enough
for anybody"). AFAIK DOS programs could address only 64 kB
chunks, because
- the processor used two registers for addressing data
(and code ?); addresses were specified as segment:offset
(and offset could only specify 64 kB)
- the compiler always kept the same value for the segment if
not told otherwise by the NEAR, FAR and HUGE modifiers.

These modifiers then told the compiler "the address is stored
in two registers, you'll have to load both before you can
access this memory location".

My Microsoft C Reference from 1990 (blurb on the back page:
"making it all make sense"), tells me the following about
memory models:
- tiny: code and data limited to 64 kB total
- small: code and data limired to 64 kB each
- medium: data limited to 64 kB
- compact: code limited to 64 kB
- large: no limits on code or data
- huge: same as large, individual arrays can exceed 64 kB (*)

(*) IIRC, a structure could not straddle two 64 kB chunks,
you'd have to take care it was in one OR the other.

When porting these old programs, I think you can just #define
NEAR, FAR and HUGE away, because modern operating systems
(Linux from the beginning?, Windows from W95 on?) don't have
this memory model, they just operate on a gigantic flat array
of memory. (Might have something to do with the MMU being
built in right into the processor, AFAIK the 8086 didn't have
this).

That's what I remember from these old times. But my memories
may be wrong.

HTH. YMMV.
Martin

Relevant Pages

  • Re: C#, Threads, Events, and DataGrids/DataSets
    ... Jon asked me to weigh in on the memory model issue below. ... there is enough wiggle room in the spec to cause grief. ... so the JIT compiler can know special things about it). ... memory cell will be access cross thread without synchronization). ...
    (microsoft.public.dotnet.general)
  • Re: Relocation truncated to fit: continued!
    ... as it doesn't contain large static data regions. ... I don't think it matters for MKL itself whether the memory model is ... the compiler complains about "relocation truncated to ...
    (comp.lang.fortran)
  • Re: And now my thoughts on Delphis survival
    ... others had to jump out of the Pascal linage during the Turbo Pascal ... days for lack of additional memory model support. ... I don't know exactly what you mean by large or huge (since that is compiler ... engineer student in that time) has totally disappeared, ...
    (borland.public.delphi.non-technical)
  • Re: Problem with realloc (I think)
    ... If Borland C++ 5.x is a 16 bit compiler, ... and depending on your memory model you won't be able ... The parameter to malloc is a size_t type, not an int. ...
    (comp.lang.c)