refactor socket impl

[stsp]

Hi, I am playing around the
idea of adding more socket
back-ends to openwatcom.
Namely I want to port some
of those supported by
libsocket
What stops me from doing so,
is the way how the sockets
are currently implemented
in OW.
https://github.com/open-watcom/open-watcom-v2/blob/master/bld/clib/posix/c/bind.c
Here we do have

#if defined( __LINUX__ )
#elif defined( __RDOS__ )
#else
  return -1;
#endif

Instead of adding more
ifdefs to every file, I'd like
to add them as a separate
set of files in a separate subdir.
Would it be possible for
someone to do such a split,
and create the linux and rdos
subdirs from the current code?
Or should that be me? :)

[jmalak]

First sockets API is part of POSIX standard and therefore it is part of OW C run-time library.
OW is multitarget and multiplatform that any part should support all valid targets.
It is reason why such guards are used.
There is no reason to divide it to separate project or separate files.
Most of code is common then no source separation is necessary. It has only sense if implementation of appropriate function is somehow target or platform specific (significantly). In such case the name of source file use suffix specific for platform.
As example

chsizlnx.c   linux implementation
chsizos2.c   OS/2 implementation
chsizqnx.c   QNX implementation
chsizwnt.c   Windows NT implementation
chsiz.c      all other targets implementation( probably same or with minimal changes)

general rule is separate implementation code to common part (for all targets) and target specific part.

[stsp]

Thanks for info. Yes, a suffixed-names split is perfectly fine too. Why I dont want to deal with ifdefs, is because the libsocket back-ends uses a lot of asm to call to VxDs, so it would be good to have the asm in a separate files. The question: is my understanding correct that currently OW provides watt32 for most 32bit targets and provides a native sockets for linux and rdos, but no impl is currently provided for 16bit targets like win16? Вторник, 20 мая 2025 г получено от Jiří Malák:

…

First sockets API is part of POSIX and is part of OW C run-time library. OW is multitarget and multiplatform that any part should support all valid targets. It is reason why such guards are used. There is no reason to divide it to separate project. Most of code is common then no source separation is necessary. It has only sense if implementation of appropriate function is somehow target or platform specific specific. In such case the name of source file use suffix specific for platform. As example ``` chsizlnx.c linux implementation chsizos2.c OS/2 implementation chsizqnx.c QNX implementation chsizwnt.c Windows NT implementation chsiz.c all other targets implementation( probably same or with minimal changes) ``` -- Reply to this email directly or view it on GitHub: #1458 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***

[jmalak]

On Windows 16/32/64-bit Winsock is standard that it doesn't need to implement it.
as example of use of TCP/IP for multiple platform is TCP/IP trap file (debugger comunication).
it is in bld/trap/tcp.
With OW you can use TCP/IP on DOS, OS/2, Windows, RDOS, QNX and Linux

Anyway OW compilers support #pragma aux to interface asm procedures in-line into C code or call asm functions from C code. That it is not a problem call VxD API from C code by appropriate C prototypes.
By example
bld/idebatch/dos uses VxD API that you can look how it is used by C code

[stsp]

Thanks, so the problem is, I have a somewhat non-standard requirements. Its good to know win16's winsock is supported, but can I switch the back-end and use the packet driver for OW sockets under win16? Its likely a default back-end for dos, but for now I need to target Packet driver on win16 - is it possible? That would give me a playground to start, but my end goal it to port the sock.vxd support from libsocket, and use it under various targets, like win16 and dos32. The full story is that I want to implement the custom winsock driver under win31, which is why I need to target other socket APIs, rather than winsock itself. Вторник, 20 мая 2025 г получено от Jiří Malák:

…

On Windows 16/32/64-bit Winsock is standard that it doesn't need to implement it. as example of use of TCP/IP for multiple platform is TCP/IP trap file (debugger comunication). it is in bld/trap/tcp. With OW you can use TCP/IP on DOS, OS/2, Windows, RDOS, QNX and Linux -- Reply to this email directly or view it on GitHub: #1458 (reply in thread) You are receiving this because you authored the thread. Message ID: ***@***.***

[stsp]

So I guess OW doesn't need any
of the libsocket back-ends, in
which case I should just rip off
the needed code from OW, turn
it into a standalone lib and do
the needed customizations there.
No one probably needs the
non-default back-ends in the
main OW code.