Having some trouble porting some code from Delphi to FreePascal running on MAC OS X (power pc). On Delphi to set a socket non-blocking I would normally do:

       flag := 1 ;
       ioctl (cpath, FIONBIO, flag) ;

However the compiler doesn't seem to recognize FIONBIO or ioctl. Another standard
Unix method would be :

       flag := 1 ;
       fcntl (cpath, FNDELAY, flag) ;

Again, those aren't recognized. I've tried adding baseunix and unix to the uses
clause (along with sockets) with no effect. Other common items not recognized are
EWOULDBLOCK and ECONNRESET socket error codes (among others I would think).

Anyone know where I can find this functionality?

Thanks,

Bob

You could use lNet which implement non-blocking sockets on all fpc platforms (well.. most) from http://members.chello.sk/ales

As for this concrete problem you need to use "fpfcntl".

Ales

Having some trouble porting some code from Delphi to FreePascal running on MAC OS X (power pc). On Delphi to set a socket non-blocking I would normally do:

Functions are prefixed by "fp", to avoid possible conflicts, and errorcodes with "esys". Constants and stuctures are not prefixed.

FIONBIO is defined in unit termio (these are not just for sockets under *nix).

IOCTLs are per definition non standard, so don't expect them (all) to be portable. Also Windows sometimes names functions differently, because it bases its network layer on pre-Posix definitions (or a Posix draft)

P.s. Note that Indy10 clients work on OS X (powerpc)

Marco van de Voort wrote

P.s. Note that Indy10 clients work on OS X (powerpc)

But Indy is entirely blocking-oriented.

Micha

Marco van de Voort wrote

FIONBIO is defined in unit termio (these are not just for sockets under *nix).

I would have never guessed :)

IOCTLs are per definition non standard, so don't expect them (all) to be portable. Also Windows sometimes names functions differently, because it bases its network layer on pre-Posix definitions (or a Posix draft)

I've gotten those to compile, it will be a while before I find out if they do
anything.

P.s. Note that Indy10 clients work on OS X (powerpc)

Maybe I should explain what I'm doing. I wrote a library to communicate with a
earthquake recording system. Most of the code was adapted from an existing Delphi
project but modified to allow one thread per remote system rather than running a
new copy of the entire program per remote station.

This library will have to be downgraded to plain "C" for distribution to other
(mostly university) users to incorporate into their programs. Before I do that I
wanted to make sure it would work on a big-endian machine and the G4 Mac Mini is
the only big-endian machine I have around here. I conditionalized the code using
ENDIAN_LITTLE so I don't expect many problems.

The biggest problem I'm having is that FPC is different from both Win32 and Posix
so it hasn't been straight forward.

Thanks

Bob

Robert Reimiller wrote

The biggest problem I'm having is that FPC is different from both Win32 and Posix so it hasn't been straight forward.

FPC's *nix interface is pretty much entirely based on Posix, only with a few naming conventions:

* all Posix functions are prefixed with fp (to avoid naming clashes between e.g. Pascal's close and Posix' close)
* the things Marco mentioned

Jonas

Marco van de Voort wrote: > P.s. Note that Indy10 clients work on OS X (powerpc) But Indy is entirely blocking-oriented.

It depends on what the OP's intentions are. He asked for non-blocking sockets, but that could be a result of porting some lib for which LNet or Indy could be a substitute, not a hard requirement for non-blocking.

In quite a few cases "var" parameters are used instead of pointers, that's the
other major difference I found when porting from delphi. Maybe those were in the
socket functions. I remember stuff like getsockopt in winsock that used pointers
where in fp it used getsocketoptions and var parameters.

fpgetsockopt uses pointers. getsocketoptions is an older (1.0.x) compability function.

Must of have missed it, too many choices :)

Got the program working (it's about 20000 lines of code) with the MD5 causing me the most grief. Found a bunch of places where my endian handling was wrong so it was worth the 15 hours effort. Unfortunately now I have to start translating it to "C", I HATE C!!!

I don't know how you can keep all those different operating systems and processors straight in your mind, an amazing feat. I think I was initially supporting 3 or 4 operating systems back when I was doing 6809 Pascal (and later in the 80's 68000) but didn't have nearly the processors to support.

Thanks,

Bob

Marco van de Voort wrote

fpgetsockopt uses pointers. getsocketoptions is an older (1.0.x) compability function.

Must of have missed it, too many choices

Got the program working (it's about 20000 lines of code) with the MD5 causing
me the most grief. Found a bunch of places where my endian handling was wrong
so it was worth the 15 hours effort. Unfortunately now I have to start translating
it to "C", I HATE C!!!

I don't know how you can keep all those different operating systems and processors
straight in your mind, an amazing feat. I think I was initially supporting 3 or 4
operating systems back when I was doing 6809 Pascal (and later in the 80's
68000) but
didn't have nearly the processors to support.

Thanks,

Bob

A wonderful development environment your OmegaSoft Pascal, I loved it!

Martin