History of far memory...?

[Eric A. Johnson]

Hi,

The book I am studying from, which comes from 1994, makes mention of far
memory (i.e., that memory beyond 64K). I am under the belief, however, that
far memory no longer needs any special statements, such as _fmalloc,
farmalloc, far char pointers, etc., to differentiate it from near memory. I
know that this is true under Win32. Is this true in the ANSI standard, as
well? Also, should I assume that any statements dealing with far memory
should be replaced with an appropriate non-far statement?
Also, I've never before (until just now) even heard of a far char pointer.
Can somebody explain to me what it is, why it was used, and how to replace
it should I come across it? When, and why, did far go out of use?

Thanks,
Eric A. Johnson

 

[Ben Pfaff]

The book I am studying from, which comes from 1994, makes
mention of far memory (i.e., that memory beyond 64K). I am
under the belief, however, that far memory no longer needs any
special statements, such as _fmalloc, farmalloc, far char
pointers, etc., to differentiate it from near memory. I know
that this is true under Win32.

The concepts of "far" and "near" memory are non-standard
MS-DOSisms. They are irrelevant in other environments.

Is this true in the ANSI standard, as well? Also, should I
assume that any statements dealing with far memory should be
replaced with an appropriate non-far statement? Also, I've
never before (until just now) even heard of a far char pointer.
Can somebody explain to me what it is, why it was used, and how
to replace it should I come across it? When, and why, did far
go out of use?

I'd get a better book, one that's about C instead of about MS-DOS
variants on C. You can usually do okay by just dropping `near'
or `far' and using standard substitutes for functions, such as
malloc() instead of whatever `near' or `far' variant your MS-DOS
compiler has. But for novices who don't know standard from
non-standards, you're likely to end up pretty confused.

 

[Michael Mair]

Hi,

The book I am studying from, which comes from 1994, makes mention of far
memory (i.e., that memory beyond 64K). I am under the belief, however, that
far memory no longer needs any special statements, such as _fmalloc,
farmalloc, far char pointers, etc., to differentiate it from near memory. I
know that this is true under Win32. Is this true in the ANSI standard, as
well? Also, should I assume that any statements dealing with far memory
should be replaced with an appropriate non-far statement?
Also, I've never before (until just now) even heard of a far char pointer.
Can somebody explain to me what it is, why it was used, and how to replace
it should I come across it? When, and why, did far go out of use?

See Ben Pfaff's reply.

A word to the wise: This is the second time that something from your
ominous book is not quite up to the challenges of a fifteen year old
standard. Treat it as obsolete and try to get another one.
See the comp.lang.c FAQ starting at
http://www.eskimo.com/~scs/C-faq/top.html
for literature and of course many thoroughly answered problems.
For a beginner: Try to get your hands on a copy of K&R2.

Do not use any books by Herbert Schildt -- he is a major source of
misinformation, wrong ideas and plain *** about C.


Cheers
Michael

 

[Kenneth Brody]

The concepts of "far" and "near" memory are non-standard
MS-DOSisms. They are irrelevant in other environments.

[...]

Actually, it's more of a segmented-memory-hardware-platform'ism than it
is an MS-DOSism. Long ago, I ported our 68000-Xenix software to a 286-
Xenix platform. (The 286 having the same 16-bit segmented architecture
that the original 8088 used by MS-DOS had.) The C compiler there also
had the concept of far and near pointers.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Big K]

Hi,

The book I am studying from, which comes from 1994, makes mention of far
memory (i.e., that memory beyond 64K). I am under the belief, however, that
far memory no longer needs any special statements, such as _fmalloc,
farmalloc, far char pointers, etc., to differentiate it from near memory. I
know that this is true under Win32. Is this true in the ANSI standard, as
well? Also, should I assume that any statements dealing with far memory
should be replaced with an appropriate non-far statement?
Also, I've never before (until just now) even heard of a far char pointer.
Can somebody explain to me what it is, why it was used, and how to replace
it should I come across it? When, and why, did far go out of use?

Thanks,
Eric A. Johnson

Return that book to the library, and for your next choice, ask a C
expert instead of your local librarian (unless he/she is a C expert).

As others have said, get K&R2 if at all possible:
[Title: The C Programming Language
Authors: Brian Kernighan, Dennis Ritchie
ISBN: 0131103628]

For a couple of months, ignore Operatings Systems, Hardware, etc. and
just worry about the details of Standard C.

 

[Eric A. Johnson]

See Ben Pfaff's reply.

A word to the wise: This is the second time that something from your
ominous book is not quite up to the challenges of a fifteen year old
standard. Treat it as obsolete and try to get another one.
See the comp.lang.c FAQ starting at
http://www.eskimo.com/~scs/C-faq/top.html
for literature and of course many thoroughly answered problems.
For a beginner: Try to get your hands on a copy of K&R2.

Do not use any books by Herbert Schildt -- he is a major source of
misinformation, wrong ideas and plain *** about C.

Okay, I will avoid books by Herbert Schildt... thanks for the tip. I have
another book on C, but it is for beginners... I've gone through much of it,
but I wanted to learn more advanced topics. Still, there are many things
about this book that don't cut the mustard. I will go on to another book...
perhaps K&R2, as many of you have suggested.

 

[Eric A. Johnson]

Hi,

The book I am studying from, which comes from 1994, makes mention of far
memory (i.e., that memory beyond 64K). I am under the belief, however, that
far memory no longer needs any special statements, such as _fmalloc,
farmalloc, far char pointers, etc., to differentiate it from near memory. I
know that this is true under Win32. Is this true in the ANSI standard, as
well? Also, should I assume that any statements dealing with far memory
should be replaced with an appropriate non-far statement?
Also, I've never before (until just now) even heard of a far char pointer.
Can somebody explain to me what it is, why it was used, and how to replace
it should I come across it? When, and why, did far go out of use?

Thanks,
Eric A. Johnson

Return that book to the library, and for your next choice, ask a C
expert instead of your local librarian (unless he/she is a C expert).

As others have said, get K&R2 if at all possible:
[Title: The C Programming Language
Authors: Brian Kernighan, Dennis Ritchie
ISBN: 0131103628]

I will look for K&R2 asap! Thanks for your help.

 

[Eric A. Johnson]

Hi,

The book I am studying from, which comes from 1994, makes mention of far
memory (i.e., that memory beyond 64K). I am under the belief, however, that
far memory no longer needs any special statements, such as _fmalloc,
farmalloc, far char pointers, etc., to differentiate it from near memory. I
know that this is true under Win32. Is this true in the ANSI standard, as
well? Also, should I assume that any statements dealing with far memory
should be replaced with an appropriate non-far statement?
Also, I've never before (until just now) even heard of a far char pointer.
Can somebody explain to me what it is, why it was used, and how to replace
it should I come across it? When, and why, did far go out of use?

Thanks,
Eric A. Johnson

Return that book to the library, and for your next choice, ask a C
expert instead of your local librarian (unless he/she is a C expert).

As others have said, get K&R2 if at all possible:
[Title: The C Programming Language
Authors: Brian Kernighan, Dennis Ritchie
ISBN: 0131103628]

I will look for K&R2 asap! Thanks for your help.

Note: I did a search online and discovered this book at a local library...
not the one I usually go to, but still not far from me. It's on the shelf,
so I will get it tomorrow morning, as soon as they open. If the book is
helpful enough, I will purchase it right away, as well. Thank you all for
recommending this book to me!

-- Eric

 

[Neil Kurzman]

See Ben Pfaff's reply.

A word to the wise: This is the second time that something from your
ominous book is not quite up to the challenges of a fifteen year old
standard. Treat it as obsolete and try to get another one.
See the comp.lang.c FAQ starting at
http://www.eskimo.com/~scs/C-faq/top.html
for literature and of course many thoroughly answered problems.
For a beginner: Try to get your hands on a copy of K&R2.

Do not use any books by Herbert Schildt -- he is a major source of
misinformation, wrong ideas and plain *** about C.

Cheers
Michael

Herbert Schildt
I found his book helpful back in the day. It covered topics not in the beginners
books. True the examples where not ANSI. I do not know how well it holds up.

far is not obsolete by the way. It is of course not standard. But There are
plenty of 8 and 16 bitters that still use it.

 

[Michael Mair]

Herbert Schildt
I found his book helpful back in the day. It covered topics not in the beginners
books. True the examples where not ANSI. I do not know how well it holds up.

I had the first contact with his books a few years ago when I started
out to make a new C course for students; naturally, I went to the
library, took what was there (>=50% Schildt), asked whether our chair
had also some C books and got "C - the complete reference" from Schildt.
I started leafing through the books and saw some things which where
slightly off the mark or "somehow not C" (the concepts were wrong so
that a newbie could get a completely wrong impression). I started out
googling, went through the lysator page and from there, I arrived at
a scathing review of a Schildt book. I read with feelings of horror
through the examples. As I had no C99 book at my fingertips first, I
looked the things up in Schildt's book and double-checked them with
internet resources. In the end, I got myself N869 and then the standard
in order to get it right. For the few bugs I spotted myself, the term
"bullschildt" is well-deserved.
The main problem is IMO not that a couple of examples is wrong -- it
is that readers get a slightly to completely wrong impression of how
things work, how they are done, what to take care of and so on.
This makes the Schildt books plain dangerous.
And for many people it means that, at some point, they have to unlearn
and relearn things that already may have grown into language "reflexes".
This costs time -- and sometimes money.
I am glad that I started learning C on the Amiga -- and thus did not
have the opportunity to fall for the "professional" programming advices
of Herbert Schildt.

far is not obsolete by the way. It is of course not standard. But There are
plenty of 8 and 16 bitters that still use it.

I never claimed different.


Cheers
Michael

 

[Malcolm]

The book I am studying from, which comes from 1994, makes mention of > far

memory (i.e., that memory beyond 64K). I am under the belief,

however, that
far memory no longer needs any special statements, such as _fmalloc,
farmalloc, far char pointers, etc., to differentiate it from near memory. I
know that this is true under Win32. Is this true in the ANSI standard, as
well? Also, should I assume that any statements dealing with far memory
should be replaced with an appropriate non-far statement?
Also, I've never before (until just now) even heard of a far char pointer.
Can somebody explain to me what it is, why it was used, and how to
replace it should I come across it? When, and why, did far go out of use?

In C, a pointer holds an address, that is to say the address of any
variable.

However this causes problems on some architectures. The old x86 chips
divided memory into 64K segments. You could then access the segment through
a 16-bit offset register.

So a C program could use 16 bit pointers, as long as it was limited to 64K
of memory. So one solution is to limit your program to 64K (the small memory
model). Another solution is to use 32 bits for pointers and store the
segment register as well as the offset register in the pointer (the huge
memory model).

The problem with the huge memory model was that carrying aound the segment
and the offset was slow. A lot of real programs like to have a small amount
of frequently accessed data, and a large amount of data that is accessed
less often (eg if you were doing a payroll you would step through the array
of employees only a few times, but you would access the company account
information for each employee).
So it makes sense to store the frequently-accessed data in a default
segment, and access it with 16-bit pointers, and to access the remained of
the memory with "far" pointers.

However a modern PC accesses everything with 32-bit pointers, so you don't n
eed far memory, though we might go back to it if PC memory sizes creep up
over 4GB.
Also you don't need to worry about far memory if you are writing a program
for an old DOS compiler, unless efficiency is a serious concern, which it
generally isn't for learning programs. Just use plain char *s and malloc() /
free() and compile in huge mode if you need more memory.

 

[Eric A. Johnson]

memory (i.e., that memory beyond 64K). I am under the belief,
In C, a pointer holds an address, that is to say the address of any
variable.

However this causes problems on some architectures. The old x86 chips
divided memory into 64K segments. You could then access the segment
through
a 16-bit offset register.

So a C program could use 16 bit pointers, as long as it was limited to 64K
of memory. So one solution is to limit your program to 64K (the small
memory
model). Another solution is to use 32 bits for pointers and store the
segment register as well as the offset register in the pointer (the huge
memory model).

The problem with the huge memory model was that carrying aound the segment
and the offset was slow. A lot of real programs like to have a small
amount
of frequently accessed data, and a large amount of data that is accessed
less often (eg if you were doing a payroll you would step through the
array
of employees only a few times, but you would access the company account
information for each employee).
So it makes sense to store the frequently-accessed data in a default
segment, and access it with 16-bit pointers, and to access the remained of
the memory with "far" pointers.

However a modern PC accesses everything with 32-bit pointers, so you don't
n
eed far memory, though we might go back to it if PC memory sizes creep up
over 4GB.
Also you don't need to worry about far memory if you are writing a program
for an old DOS compiler, unless efficiency is a serious concern, which it
generally isn't for learning programs. Just use plain char *s and malloc()
/
free() and compile in huge mode if you need more memory.

Thanks for the lesson and the tips! It's terrific to have somebody willing
to give me a bit of a history lesson and advice at the same time. I
appreciate it!

-- Eric