A few of these functions have macros for easier use (select, inet_ntoa, etc.), but you must use CloseSocket and IoctlSocket in place of close and ioctl. Bsdsocket.library has it's own ernno, which can be queried with Errno() or you can make it use the errno variable using SetErrnoPtr() or SocketBaseTagList()

Make sure the bsdsocket.library is opened before you call the bsd functions, if not than its very normal that is where it crashes...

For example you create a socket with socket() (from bsdsocket.library) and then you pass it to write() from arosc, but this integer value means something different to arosc. Same with other way around, using fd created by arosc with bsdsocket.library.

Do you know that bsdsocket API has support for fd hooks. They allow to sync up fd numbers between bsdsocket.library and libc. If you look at original netlib code, you'll see it. That implementation is based on some support from SAS/C libc.

Every bsdsocket.library call takes SocketBase as an argument, and since you declared a global NULL SocketBase socket functions will fail. To solve the problem, you can include the header blow instead of proto/bsdsocket.h, and use SocketBase as normal, which will become the taks's user defined field. Please note that you have to do call init_arossock() in the right thread, preferably in a wrapper around exec_list, and don't declare a global SocketBase variable.

As far as i know WaitSelect() works just like select() and would be nice to paste bit of the code here where it fails... WaitSelect can only be used on sockets, not on DOS filehandles. On unix they are handled uniformly, but on Amiga you have to use different code path for file handles and sockets.

One of the arguments of LockMutex is still NULL, it could be ThreadBase too. One thing I noticed is that you don't use pthread_join/WaitThread in your code. Instead you do busy loops until the given thread sets its state. Because one of the functions which overflows the stack is wait_thread_running().

LockMutex fails in exe_elist(), because cclist_mutex is not itialized for AROS in main.c, hence the NULL pointer.

Initializing cclist_mutex solves the problem. Here are the two thread-waiting functions without the busy loop:

Replacing WaitThread with pthread_join would work on other platforms. Checking (pthreads[i].state == PTHREAD_RUNNING) isn't necessary anymore, since these thread waiting functions instantly return on terminated threads.

It's waiting till the thread is started (was created). It's the thread_sync function in the examples. This is for synchronizing threads. The next step would be sendig data to the thread: with threadpush ().

Also make sure that to open bsdsocket.library in the same thread where you do the socket operations, because you can't share socket descriptors between threads. Technically it's possible to pass sds between threads, but it requires some extra code, and generally not worth the hassle if you can move all the socket manipulation into one thread.

The first is about breaking some api level functionality to make way for supporting IPv6. Would it be a great deal to fix the existing functions that assume IPv4 addresses, so they take generic structures instead? miami.library provides the missing API. Miami was going the same way those back then. IPv6 looks like a failed experiment. No one is seriously deploying it. In fact not much needs to be replaced. It affects mainly resolver, introducing inet_PtoN() and inet_NtoP(). The rest is perfectly handled by existing socket API. Just add AF_INET6.

How big a task would it be to replace the existing bsd-based internals of AROSTCP with more upto date code? Take recent NetBSD and you're done. FreeBSD diverted a lot. This will give you working sysctl and BPF/PCAP. AROSTCP already has some upgraded code. Its codebase is NetBSD v2.0.5. BTW, userland (like resolver) from FreeBSD perfectly fits in. One more idea: separate protocols into loadable modules. This would give you AF_UNIX, AF_BT, etc. There is a single-linked list where all protocols are registered. Nodes are looked up using AF_xxx as a key. Then there are several pointers to functions. That's all. This is very well separate-able. In the end you would have protocol modules with these functions exported, and something like bsdcore.library, implementing basic lowlevel stuff like mbufs and bsd_malloc(). Ah, yes, there is some remainder (IIRC) from original BSD4.3, where AF_xxx are indexes into array. I was lazy enough not to remove this. So, for now both lookup mechanisms are coexisting. Throw away the old one, use NetBSD code as a reference. In fact BSD is very modular at source code level, the same as Linux. You can switch on and off any part without affecting others. So, porting the code isn't really difficult.

Would like to propose a 'unified file descriptor' model for arosc.library, to simplify porting of POSIX applications. The goal is to be able to use the same 'int fd' type to represent both the DOS BPTR filehandles and bsdsocket.library socket backend. This will eliminate the need to rewrite code to use send() instead of write() to sockets, and call CloseSocket() instead of close() for sockets.

Implementation would be as a table (indexed by fd #) that would have the following struct:

Set fd_table[fd].ops to a 'struct arosc_fd_operation' pointer, that defines the IO operations for either dos.library for bsdsocket.library

Set fd_table[fd].file to a pointer to the private data for those operation (ie BPTR or socket fd #)

Return the new FD number

The read()/write()/etc. would be modified to use the fd_table[fd].op routines to perform IO

The poll() routine will wait for activity on the OR of all the signal masks of the the provided FDs.

The close() routine also deallocates the arosc_fd entry

It's a layer on top of it. bsdsocket.library would be opened dynamically from arosc.library's socket() routine if needed.

since arosc generated FD's will be different from bsdsocket.library ones how will programmers know what to pass to functions? Programmers would not use the bsdsocket headers nor protos directly (similar arosc.library headers would be generated that wrap them). The point is that programmers would no longer need to treat bsdsocket fd as a special case.

the whole fd_table[] mapping concept. The 'file' element of the fd_table[n] would be a BPTR for a open()ed fd, and a bsdsocket.library socket descriptor number for one created by arosc's socket() call. The user would *not* be calling bsdsocket.library directly under the proposed scheme. Everything in that library would be wrapped by arosc.library.

make sure that those codes will continue using bsdsocket functions and won't switch half arosc / half bsdsocket (for example arosc->send and bsdsocket->CloseLibrary). The 'best' solution would be to have a compilation flag (ie

'#define BSDSOCKET_API') that ifdefs out the arosc send()/recv()/socket()/etc prototypes and makes send()/recv()/CloseSocket() and friends from the bsdsocket protos visible.

If BSDSOCKET_API is not defined, but bsdsocket.library is intended (ie calls to CloseSocket(), etc), then the user will get compilation errors about missing function prototypes. If BSDSOCKET_API is defined, but POSIX is intended, then they will get a link error about 'undefined symbol SocketLibrary'

Maybe the bsdsocket includes should also have some detection of arosc includes and produce the warning about the BSDSOCKET_API define beeing accessible to developers if both headers are included in the same compilation unit - I'm just wondering how we are going to get the word out to 3rd party developers that they don't have to change their codes and can simply use the define - or maybe it should be the other way around? bsdsocket by default and POSIX_SOCKET_API define to enable the support you mention?