From:	Erwann ABALEA <erwann AT abalea DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: about ansi c compilation
Date:	Wed, 23 Jun 1999 15:31:48 +0200
Organization:	Halfling Soft
Lines:	25
Message-ID:	<Pine.OSF.4.05.9906231529030.17006-100000@fermi.cnam.fr>
References:	<01beb670$93a7e980$d04b05c3 AT antonio>
NNTP-Posting-Host:	fermi.cnam.fr
Mime-Version:	1.0
X-Sender:	abalea_e AT fermi DOT cnam DOT fr
In-Reply-To:	<01beb670$93a7e980$d04b05c3@antonio>
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 14 Jun 1999, Antonio wrote:

> I am almost a newbye in djgpp programming, but so far it seems to me that
> djgpp can't compile ansi c (for ex. a program not using assembler written 4
> linux) because of the far pointers, is it so? Why not use a 64 bit var for
> far pointers in order to save EIP:ECX instead of using poke and peek
> procedures to access all of the memory?

Well.... ANSI C surely has nothing to do with assembly language...

DJGPP respects the ANSI C standard, because it's based on the gcc
compiler...

There's no such thing as far or near pointers in DJGPP, since you are in
protected mode, so a pointer is always a selector and an offset (somewhat
similar to segment:offset, but the arithmetic and security is a lot
different).

Why do you want to use poke&peek to access al the memory? AFAIK, poke and
peek are not part of the standard libc...

-- 
Erwann ABALEA
erwann AT abalea DOT com

- Raw text -