Mail Archives: djgpp/1997/12/29/04:52:34
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
- Raw text -