Hello,

Don't know if the subject line makes sense but here'goes anyway.  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.

It sounds as though far is typedef'd as some sort of 32 bit int.
Perhaps, I could be totally wrong too.  Except for two very simple dos
prompt programs, I've never programmed for M$.  (I'd actually like to
keep it that way.)

In any event, I was wondering if anyone here could tell me what the far
type would translate too in linux?  For example, how would I read a line
like this?:

void far *LinkAddress;

What the heck is going on there?  I thought void was a type.  How can
you have two types for the same variable?  Would that simply be
something like?:

int *LinkAddress;

Thanks in advance.

---------------------------------------------
Andrew R. Falanga (a non-HP employee)
Hewlett-Packard Company
11311 Chinden Blvd.
Boise, Idaho
---------------------------------------------
Please note: The e-mail address is purposely
mangled.  I do not wish my account at HP to
become a spam haven.

[ Post a follow-up to this message ]

Andrew Falanga <falandr@hp.com> wrote:
> Don't know if the subject line makes sense but here'goes anyway.  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.

> It sounds as though far is typedef'd as some sort of 32 bit int.
> Perhaps, I could be totally wrong too.  Except for two very simple dos
> prompt programs, I've never programmed for M$.  (I'd actually like to
> keep it that way.)

Me too;-)

> In any event, I was wondering if anyone here could tell me what the far
> type would translate too in linux?

To nothing. To Linux all memory was created equal, so there's nothing
like near, far or huge (and what you use are virtual addresses anyway,
not physical addresses like under DOS, so where a variable is going to
end up in physical memory is completely unspecified during compilation
and may even still change while the program is running). If you have a
program using them that you want to port to Linux just delete them or
define them to do nothing, e.g.

#define far

> For example, how would I read a line
> like this?:

> void far *LinkAddress;

> What the heck is going on there?  I thought void was a type.  How can
> you have two types for the same variable?

That's not another type but a (non-standard) additional qualifier.
It's not that uncommon, you can have other, standard qualifiers like

void const *Fixed_Port_Address = 0x378;

or

const void *Read_Only_Address;

etc. That doesn't make 'const' an additional type but qualifies the
type, i.e. that the pointer is to be taken to be unmutable or what
it points to.
Regards, Jens
--
\   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
\__________________________  http://www.toerring.de

[ Post a follow-up to this message ]

"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

[ Post a follow-up to this message ]

On 2004-08-27, Andrew Falanga <falandr@hp.com> wrote:

> In any event, I was wondering if anyone here could tell me what the far
> type would translate too in linux?  For example, how would I read a line
> like this?:
>
> void far *LinkAddress;
>
> What the heck is going on there?  I thought void was a type.  How can
> you have two types for the same variable?  Would that simply be
> something like?:
>
> int *LinkAddress;

Yes. To port DOS C code to a flat memory model environment such
as i386 Linux, you can just remove the "far" and "huge"
qualifiers, and use malloc() instead of farmalloc() and halloc()
and free() instead of farfree() and hfree().

#define far
#define farmalloc malloc
#define farfree   free
#define huge
#define halloc    malloc
#define hfree     free

The "far" and "huge" qualifiers are an artefact of the segmented
architecture of the 8086. On the 8086, pointers can be 16-bit
long or 32-bit long. A "far" or "huge" qualifier states that
this is a 32-bit pointer. This is necessary when you have more
the 64 kB of code or data.

Conversely, "near" states that this is a 16-bit pointer.

In the absence of a qualifier, pointers use the default model,
which can be near, far or huge, as specified by the relevant
compiler flags.

> It sounds as though far is typedef'd as some sort of 32 bit int.
> Perhaps, I could be totally wrong too.

"far" means that the pointer is made of a 16-bit segment number
plus a 16-bit offset. The total size is indeed 32-bit although
the addressable space is only 20-bit because the 8086 calculates
the effective address like this : segment << 4 + offset.

A "near" pointer is just a 16-bit offset. The segment number is
implied and comes from the relevant segment register (CS for
code, DS for data, etc.) The advantage of near pointers is that
they're small and fast. The drawback is that you're limited to
64 kB of code and 64 kB of data.

"huge" is the same thing as "far" except that the object can be
larger than 64 kB.

--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
"See daddy ? All the keys are in alphabetical order now."

[ Post a follow-up to this message ]

> In any event, I was wondering if anyone here could tell me what the far
> type would translate too in linux?  For example, how would I read a line
> like this?:

Takes me back to my DOS assembler days  tiny, compact, small, etc. were
memory models. They just helped a compiler organize where in memory they
would place chunks of code, and chunks of data.

With modern OS's where you have virtual memory, you just see a flat 32-bit
address space. The OS takes care of shuffling where it wants to put your
pages of memory in physical RAM or disk, and you don't worry about it.

In pure DOS, memory was available as segment:offset where both were 16-bit
values. Because instructions normally execute within one offset at a time,
you were pretty much limited to 16 bits = 64 KBytes of memory. So the
question became, where are you going to put your code, data, and stack.
With the tiny model you would shove them all within one segment for
instance. With the larger models the compiler did strange tricks to make
use of multiple segments, escaping from the 64 KB limit.

--
Jem Berkes
http://www.sysdesign.ca/

[ Post a follow-up to this message ]

Jem Berkes wrote:
 
>
> Takes me back to my DOS assembler days  tiny, compact, small, etc. were
> memory models. They just helped a compiler organize where in memory they
> would place chunks of code, and chunks of data.
>
> With modern OS's where you have virtual memory, you just see a flat 32-bit
> address space. The OS takes care of shuffling where it wants to put your
> pages of memory in physical RAM or disk, and you don't worry about it.
>
> In pure DOS, memory was available as segment:offset where both were 16-bit
> values. Because instructions normally execute within one offset at a time,
> you were pretty much limited to 16 bits = 64 KBytes of memory. So the
> question became, where are you going to put your code, data, and stack.
> With the tiny model you would shove them all within one segment for
> instance. With the larger models the compiler did strange tricks to make
> use of multiple segments, escaping from the 64 KB limit.
>
I remember using DOS to write test software for modules where we had to test
and keep track of 96 channels of data. You had to be very careful even with
lage model to keep from running agains the segment limit, this was a
problem with MSC ver 4 though 6, despite what the documentation implied. I
generally used float instead of double for data types, and did not keep as
much data around as I wanted to.

--
Mike McGinn

[ Post a follow-up to this message ]

Thank you all for your responses.  Sounds like this won't be as much a
deal as I thought.  Whoever, or whomever, thought up virtual memory ...
thank you.  This other models sounds rather like a pain to work with.

Thanks again everyone.

---------------------------------------------
Andrew R. Falanga (a non-HP employee)
Hewlett-Packard Company
11311 Chinden Blvd.
Boise, Idaho
---------------------------------------------
Please note: The e-mail address is purposely
mangled.  I do not wish my account at HP to
become a spam haven.

[ Post a follow-up to this message ]

On Mon, 30 Aug 2004, Andrew Falanga wrote:

> Thank you all for your responses.  Sounds like this won't be as much a
> deal as I thought.  Whoever, or whomever, thought up virtual memory ...
> thank you.  This other models sounds rather like a pain to work with.

Virtual memory has only been around, oh, about 10 years BEFORE the first
version of DOS shipped.  That such hacks such as "near" and "far" show
how brain damaged the design of the original x86 was* and how brain damaged
DOS was, even in the era of 386 and newer x86 CPUs.

* The equivelent motorola chip, the 68000 did not make such a mistake.
What a shame the designers of the original IBM PC didn't chose this
much better CPU for their creation...

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
published in August 2004.

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

[ Post a follow-up to this message ]

> Virtual memory has only been around, oh, about 10 years BEFORE the
> first version of DOS shipped.  That such hacks such as "near" and
> "far" show how brain damaged the design of the original x86 was* and
> how brain damaged DOS was, even in the era of 386 and newer x86 CPUs.

Well the x86 wasn't that bad for its day, but what is unfortunate is how
long it took mainstream operating PC operating systems (really, DOS/win) to
catch up to the capabilities of the 80386.

--
Jem Berkes
http://www.sysdesign.ca/

[ Post a follow-up to this message ]

On Mon, 30 Aug 2004, Jem Berkes wrote:

> Well the x86 wasn't that bad for its day, but what is unfortunate is how

Yes it was--the 68000 is proof of that!

> long it took mainstream operating PC operating systems (really, DOS/win) t
o
> catch up to the capabilities of the 80386.

Agreed.  That's what happens when you have a monopoly that isn't
interested in innovation.

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
published in August 2004.

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

[ Post a follow-up to this message ]