C Socket Programming (with OSLib?)

I am wanting to do some IRC stuff over a socket connection with C code. I have seen some online resources and source code for apps like !Nettle (an ssh terminal) doing `#include “sys/socket.h”` but when I use the DDE compiler to compile a file with that header file, it says ‘File “sys/socket.h” wouldn’t open’

…and it seems that the socket API provided by OSLib is not the same as what is provided by “sys/socket.h”, because in examples using that header file (like !Nettle), there are calls such as `socket(AF_INET, …)` while OSLib’s header file defines “socket_AF_INET” (with socket_ prefix) and “socket_creat()”

Here are a couple examples using “sys/socket.h”

https://heyrick.eu/blog/index.php?diary=20160104
https://github.com/dpt/Nettle/blob/533af898bd3cf9cecd7b558b153e0cff69097e6a/nettle/c/socket#L46

That is all to say, I am feeling quite lost on how to use sockets in C. I am confused about the distinction between SockLib, UnixLib, and OSLib. Which of these should I use and how can I use them?

I feel your pain, I am no sure I am going to add much that will help but I will give it a try.

Back in the day so to speak there was the “TCP/IP protocol suite programmers guide” AES33, and it came with a floppy disc.

So depending on the age of the system you are working on its reasonable possible that Norcroft C may not have the headers or InetLib, SockLib etc as they were a separate product.

Modern versions of DDE do include them, I find find AcornC/C++.Export.APCS-32.LibTCPIPLibs.sys.h.socket on my Pi400

I think there are a cope of things called unixlib floating around, the first for Norcroft includes a range of things you would find on unix that were missing from risc os the second is part of the the !GCC or GCCSDK. Normally on Norcroft you link with stubs for the shared C library module where with GCC you link with unixlib for all the standard C library functions.

OSLib C bindings can be used with either Norcoft or GCC and provides function calls for all RISC OS swis (so not the unix portabilility or standard C lib functions, but all the rest of risc os)

Without having ever used it I would say for sockets you would want to stay away from OSLib and use the UNIX flavor of header files that you will get with Norcorft or GCC. That will give you maximum compatibility with example code from other platforms.

When using socket on RISC OS you will often need to make them non blocking. On other platforms you can call the socket api and have your program block on that and its fine but you can’t write risc os desktop apps like that. There is a module called socketwatch to help with desktop apps and sockets.

But first you have to work out if you have the header and link files at all.

Generically if you are writing a RISC OS Module you are better off with Norcroft C, if you are trying to port code or libraries from elsewhere you are better off with !GCC or much better off with GCCSDK on Linux.

There is an art form to getting the search paths right for Norcroft with all the libraries you need, unfortunate I don’t have a modern machine with just out of the box Norcroft to test with, mine have the RISC OS Build system which seem to take that over somewhat.

I also caused my self a lot of grief installing the RISC OS ports of GNU core utils, without care this will break Norcroft C.

I hope that sheds a bit of light on it, but first you have to find out if you have a file called ‘socket’ (ie h.socket in our namespace) on your system. Its going to be easier to work out how to include if you know where it is.

Alan

Thanks Alan!

I have located AcornC/C++.Export.APCS-32.Lib.TCPIPLibs.sys.h.socket! To be clear I am using Norcroft on RISC OS on a raspberry pi 4 and not !GCC or any kind of Linux environment to build my RISC OS code.

I see that !Nettle uses socketwatch. I will have to learn how to use it. Perhaps I will be able to learn how to use it just by reading their code.

So, if TCPIPLibs and socketwatch are not seen by the norcroft compiler, how can I make it recognize these libraries?

I’m not at my RISC OS machine at the moment, but if you’re using shared makefiles with the DDE then you’ll need to make sure you’re including the networking libraries:

LIBS += ${NET5LIBS}

Really simple dumb server.

https://heyrick.eu/blog/index.php?diary=20160104

Note the comments, some better ways are suggested.

Thanks Chris! I am using the shared makefiles. Currently they are not different than the one here:

https://www.stevefryatt.org.uk/risc-os/wimp-prog/a-better-way-to-compile

So I tried a couple things, one being:

LIBS = ${NET5LIBS} SFLib:o.SFLib OSLib:o.OSLib32

and

LIBS = SFLib:o.SFLib OSLib:o.OSLib32
LIBS += ${NET5LIBS}

for both attempts, this line was the same:
CINCLUDES = -IC:,OSLib:,SFLib:

I am getting ‘#include file "sys/socket.h wouldn’t open’ on compilation. If there is something I need to put into CINCLUDES, I’m not sure what it would be. The OSLib and SFLib libraries work fine.

The LIBS line is telling the linker where the library objects are, but the error you’re getting is the compiler not knowing where the header files are.

If there is something I need to put into CINCLUDES, I’m not sure what it would be.

Since you’re using the shared makefiles you can just add ${TCPIPINC} to the list

CINCLUDES = -IC:,OSLib:,SFLib: ${TCPIPINC}

or if you prefer to write it out verbatim

CINCLUDES = -IC:,OSLib:,SFLib:,TCPIPLibs:

does the same thing.

I see that !Nettle uses socketwatch. I will have to learn how to use it.

Socketwatch is really simple to use. It’s purpose is to make the pollword non-zero when something happens on a socket, so you can use Poll return 13 to detect activity. It saves using null polling.

That worked Sprow, thanks! It was also necessary for me to #include “sys/types.h” before including socket.h, the compiler spewed a bunch of errors before I did that.

I am getting ‘#include file "sys/socket.h wouldn’t open’ on compilation.

I suppose it would help if I actually read the message before giving advice :)

Good to see that you sorted it out (although I suspect you’d have then run into linker errors without “my” fix as well).