Message-Id: <199712290950.LAA00203@ankara.duzen.com.tr>
Comments: Authenticated sender is <mitch AT ankara DOT duzen DOT com DOT tr>
From: "S. M. Halloran" <mitch AT duzen DOT com DOT tr>
Organization: User RFC 822- and 1123-Compliant
To: djgpp AT delorie DOT com
Date: Mon, 29 Dec 1997 11:51:28 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Winsock.h parse error problem
In-reply-to: <6852am$hkb$1@newsource.ihug.co.nz>
Precedence: bulk

On 28 Dec 97, Thomas Mulgrew was found to have commented thusly:

> I'm completely new to socket programming (or windows for that matter), and 
> having a bit of trouble getting started.
> 
> When I compile a file that #includes winsock.h (using gcc -Zwin32 prog.cpp -c 
> -o prog.o  or something along those lines), the compiler reports parse errors 
> while in the winsock.h file.
> 
> Generated by lines like this:
> 
> struct hostent FAR * PASCAL FAR gethostbyname(const char FAR * name);
> 
> And the parse error is reported to be "before __attribute__"
> 
> I'm not exactly sure what FAR means in a 32bit addressing mode context, but 
> that aside I believe the line is declaring a function 'gethostbyname', to be 
> called using the pascal calling convention, and which returns a pointer to a 
> hostent structure.
> 
> What I would like to know is: what does 'FAR' mean here (can I throw them out)? 
> Do I need to change winsock.h in order to make it parse properly?, and 
> ultimately, how do I make this file parse?
> 

FAR and NEAR and other "fundamental classes of data types" like this 
are inventions necessary for the "real mode" segment-offset 
addressing architecture of the Intel x86 chips.  Intel eliminates 
this craziness with the 80386 chips and those that follow.  Intel 
must retain this crazy way of memory addressing, of course, so that 
older programs compiled can run, but with the 386 and beyond, Intel 
goes to the "flat model" (and common sense) way of memory addressing. 
The NEAR refers to an addressing space of only 16-bits (64K), while 
the FAR is for an addressing space of NOT 32-bits, but a 16-bit 
address space on a particular 16-byte paragraph of memory "segmented" 
into 16-byte paragraphs; you get the "normalized" (a term Intel uses 
in describing how to resolve the address, but they really mean 
"common sense") address by using the following logic:  memory address 
= (SEGMENT << 4) + OFFSET.  In other words, the address space is only 
20-bits (or 1 MB of memory), which explains why "real mode" is 
limited to 1 MB.  In the flat model, often understood to be 
"protected mode" (but protection really refers to a different feature 
of the cpu which makes life easy for systems programmers), the 
address is a full 32-bits.

The MS-DOS-compatible port of gcc (that is, djgpp) does not 
understand this segment:offset way of addressing memory.  Go to 
Microsoft or Borland or Watcom if you want to find a compiler for 
16-bit programs (probably the GNU group has one as well, and 
naturally it will be `free' as the term is defined under the GPL).  I 
know, because the compiler presents errors in my system-dependent 
code when it encouters 'far' or 'near' or '_seg' storage classes like 
that. You will likely need to set up proprocessing statements to 
include system-dependent code for DJGPP ("#ifdef __DJGPP__  ... and 
so on) so that your code will compile.  You might set up macros for 
FAR and NEAR to be eliminated during pre-processing; in your example 
above, you could eliminate FAR and PASCAL without getting an error.  
The compiler may have options for doing pascal-type pushing on the 
stack.


Mitch Halloran
Research (Bio)chemist
Duzen Laboratories Group
Ankara   TURKEY
mitch AT duzen DOT com DOT tr

other job title:  Sequoia's (dob 12-20-95) daddy