FAQ version 1.3.0
Last updated: 9thth June 2000
Copyright
libsocket Copyright 1997, 1998 by Indrek Mandre
libsocket Copyright 1997-2000 by Richard
Dawe
Portions of libsocket Copyright 1983-1993 Regents of the University of
California
Portions of libsocket Copyright 1991, 1992 Free Software Foundation, Inc.
Portions of libsocket Copyright 1997, 1998 by the Regdos Group
This FAQ was written by Richard
Dawe. Please see his details for
more information.
Table Of Contents
Section 1: Introduction
Section 2: Operating System Support
Section 3: Configuration
Section 4: Execution
Section 5: Programming with libsocket
Section 6: Miscellaneous Questions
Change History
Section 1: Introduction
Question 1.1: What is libsocket?
libsocket is a BSD-socket-style networking library for DJGPP programs running
under Windows.
BSD sockets are the standard way of programming networking on Unix.
BSD sockets are also available in a modified form on Windows platforms
in the form of Winsock, which has many common functions. In short, if you're
used to programming with sockets on Unix, then moving to libsocket should
be a relatively pain-free transition.
For its Winsock 1.x interface, libsocket uses a backdoor that Windows
provides to DOS programs to use Windows's networking. This backdoor is the
Winsock device driver, WSOCK.386 or WSOCK.VXD. For its Winsock 2 interface,
libsocket uses a device virtual driver (VxD) provided by the Coda network
filesystem project, SOCK.VXD.
libsocket also incorporates some source code from Linux, namely the
resolver. This resolves names of the "foo.bar.com" to IP addresses like
192.168.0.123.
Question 1.2: Who wrote libsocket?
libsocket was originally put together by Indrek Mandre. Most of the work
on this library is due to him. Unfortunately he no longer has time to look
after libsocket, and has handed over the mantle to me, Richard Dawe. Hopefully
I can keep it up to the high standards Indrek worked to.
The registry code was written by the Regdos Group.
For contributions, please see the credits, or
the relevant section in the libsocket manual page
(use "man libsocket") or info documentation
(use "info libsocket credits").
Question 1.3: Which versions of libsocket does this
FAQ cover?
Unless the version of libsocket is mentioned, it is not relevant to the
question. In other words, all versions of libsocket are covered.
Question 1.4: I have a question that is not covered
in the FAQ. What should I do?
If the question is not in the FAQ, and there is no information about the
problem in the documentation, or the documentation is not clear enough,
please e-mail me and I'll try to help. I might put it in the FAQ.
[Top]
Section 2: Operating System Support
Question 2.1: Will libsocket work with DOS?
libsocket will not work under DOS as it uses low-level Windows
functionality. It is possible a future version may work with packet drivers,
which would work with DOS.
Question 2.2: Will libsocket work with Windows 3.x?
Whether libsocket works with Windows 3.x is not known. It should work. It
should be able to obtain its configuration from the Windows .INI files, but
this is untested. Therefore it may require manual configuration. It will
require Microsoft's TCP/IP stack to work properly, since TCP/IP support
isn't built into any version of Windows 3.x. It will probably only work with
Microsoft's TCP/IP stack.
Question 2.3: Will libsocket work with Windows '95?
Windows '95 is the platform that libsocket has been written on, and is
hence the most tested. I has been tested Windows '95 with Service
Pack 1 installed and Windows '95 Operating System Release 2.1 (OSR2.1).
It will probably only work with Microsoft's TCP/IP stack.
Versions earlier than libsocket 0.7.4 beta 2 will not work if Winsock 2
is present - see
question 4.1, question 4.2,
question 6.1, question 6.2 and
question 6.3.
Question 2.4: Will libsocket work with Windows '98?
Windows '98 comes with Winsock 2 as standard. Versions earlier than
libsocket 0.7.4 beta 2 will not work if Winsock 2 is present - see -
see question 4.1 and question 4.2.
Question 2.5: Will libsocket work with Windows NT?
libsocket will not work under Windows NT. It may be possible to write a
virtual device driver (VDD) to emulate the services used by libsocket on
Windows NT.
Question 2.6: Will libsocket work with Linux?
libsocket will compile under Linux using a cross-compiler, but it should
not with the default compiler. You should not need libsocket under Linux,
since Linux's C libraries (glibc, etc.) support the BSD sockets interface
anyway.
[Top]
Section 3: Configuration
Question 3.1: How can I find out my computer's IP address?
Question 3.2: How can I find out the DNS servers' IP
addresses on my network?
Windows '95 comes with a handy, undocumented utility called winipcfg that
displays configuration information about all the available network interfaces.
Click on the "More Info >>" button to display the DNS IP addresses.
[I stated in an earlier version of this FAQ that dial-up addresses were
assigned via DHCP. This is not true - PPP assigns the addresses. Sorry.]
- libsocket has no way of obtaining the IP addresses for dial-up links in its
auto-configuration, so it has to be told. But how do you know the IP addresses?
Here's the solution (hack?): For the computer's IP address, use 127.0.0.1, the
loopback address. This will always work. You should see two lines in the hosts
file, generated by netsetup, like so:
127.0.0.1 localhost
127.0.0.1 mycomputername
The DNS IP address is trickier. This is not really a solution, but it
will probably work for a while. Log in a few times and note the DNS IP address
as given by 'winipcfg' (see question 3.1 and
question 3.2). Then use this DNS IP address when you run
netsetup. This technique will work until the DNS IP address changes, which
may or may not be infrequently.
DHCP stands for Dynamic Host Configuration
Protocol. This allocates IP addresses dynamically and allows them to be
managed and assigned from a central point.
Version 0.7.4 has support for DHCP. If the DHCP server supplies
the DNS address then it will be used.
For versions 0.7.3 & earlier, the problem is thus: libsocket
has no way of obtaining the IP addresses in its auto-configuration, so it has
to be told. But how do you know the IP addresses? Here's the solution
(hack?): For the computer's IP address, use 127.0.0.1, the loopback address.
This will always work. You should see two lines in the hosts file, generated by
netsetup, like so:
127.0.0.1 localhost
127.0.0.1 mycomputername
[Top]
Section 4: Execution
Question 4.1: Why does my program using libsocket crash?
If you have Winsock 2 installed, then libsocket 0.6 and earlier will cause
a protection fault. libsocket 0.7.0 should lead to the problem described
in question 4.2 below. If this is not the case, then
there might be a bug in your program ;)
Question 4.2: Why can't my program using libsocket
create sockets?
libsocket 0.7.0 through to libsocket 0.7.4 beta 1 will stop programs from
creating sockets if Winsock 2 is present, to prevent the protection faults
described in question 4.1. See
question 6.1, question 6.2 and
question 6.3 for more information.
Question 4.3: Why does my program using libsocket stop
working?
[ This only applies if you're using the Winsock 1.x interface, i.e. if
you're not using Winsock 2 - see question 6.1. ]
When you kill a program that listens for connections with accept()
by closing the command-prompt, the socket address it is listening on is
still marked by WSOCK.VXD as being used. So, when you try running the program
again, it can't listen on that address. The socket option
SO_REUSEADDR can be used to allow the program to bind to the port
that is marked as being in use.
[ connect() calls with the Winsock 1.x interface are now interruptable.
See question 5.6 and
question 6.1. ]
This can happen if you try to connect to a host that doesn't exist. Since
the connect() call is uninterruptable (it's a blocking call), Control-C has no
effect, and it appears that the program has crashed.
If you don't want this to happen, use non-blocking connect calls. An
interruptable solution may be possible, but needs investigation.
[Top]
libsocket can be used with multithreading libraries for multitasking, with
a couple of provisos. Firstly, the libsocket code is non-reentrant, which
means only one libsocket call should be made simultaneously, otherwise a
crash is likely and data corruption certain. Secondly, the DJGPP libraries
are non-reentrant. This limits what one can do in threads simultaneously.
I looked at two multithreading libraries for DJGPP, found in the v2tk/
directory of the DJGPP archive: jtlwp20 and pwdlwp03. The second library is
based on (an earlier version of?) the first.
With jtlwp20, there appear to be two ways of stopping the libsocket functions
being called multiply. The first method is to call
lwpCreateMutex() for all the libsocket functions you use.
The second method is to use place lwpEnterCriticalSection() and
lwpLeaveCriticalSection() around the code that uses libsocket functions.
With pwdlwp03, one has to create a semaphore using lwp_init_semaphore(),
then wait for it to become free before using libsocket calls using
lwp_wait_semaphore() and then release it when one's finished using
lwp_release_semaphore().
Please see the multithreading libraries' documentation for more details.
While libsocket's code may be non-reentrant, I don't think this totally
ruins multithreading programs. I think it would still be possible to write
a Web server that runs well in spite of the limitations.
Currently, there are not. It may, however, be possible to port the Linux RPC
code to libsocket. It should be available from any decent Linux mirror. It
has the filename rpc-0.9.tar.Z.
I was asked this question in relation to porting BSD traceroute to libsocket.
Unfortunately, it appears that only TCP stream (IPPROTO_TCP and SOCK_STREAM
options) and UDP datagram (IPPROTO_UDP and SOCK_DGRAM options) sockets can
be created with libsocket. This is a limitation of pre-2.0
Winsocks. Winsock 2.0 allows creation of any type of socket, but the
interface libsocket uses only provides the above combinations.
[This problem has been fixed with version 0.7.4 - use
"#include <sys/socket.h>".]
DJGPP includes definitions for ioctl()'s parameters in the include file
sys/ioctl.h. However, they will not be defined if you include sys/ioctl.h, as
they are enclosed in an '#if 0 ... #endif' pair. There are three
possible solutions to this problem:
Edit sys/ioctl.h so it says '#if 1' instead of '#if 0'. I do not
recommend this as it may break the compilation of many things - it certainly
stops libsocket from compiling. Besides, editing DJGPP's standard include files
has got to be a bad idea.
Use the include file winsock.h, included with libsocket, which defines
what you need.
This problem affects the compilation of programs that use non-blocking
sockets, i.e. the FIONBIO parameter for ioctl(). I would recommend including
winsock.h to circumvent this problem.
[ This problem has been fixed with version 0.7.4 beta 4. ]
DJGPP's C library, libc, doesn't come with all the Unix error messages built
in, so when you use perror() or strerror() with socket errors, no error message
is known.
Version 0.7.3 & later provide the functions lsck_perror() and
lsck_strerror(), which work the same way, to provide these error messages. If
the error isn't a socket error, then it is passed to the libc perror() and
strerror() functions. So, the solution is to replace occurrences of perror()
with lsck_perror() and strerror() with lsck_strerror(), until libc contains all
the error messages needed.
Another solution is to patch DJGPP's libc, the standard C library. This
will affect all programs, and so is dangerous if the patched code is buggy.
There is a libc patch, which should be OK,
since the code it modifies is simple.
libsocket supports much of the BSD standard. The following tables list its
compatability. Some of the limitations are due to limitations in Winsock rather
than libsocket.
Non-blocking I/O Support |
Function |
Winsock 1.x (wsock interface) |
Winsock 21 (csock interface) |
accept() |
Y2 |
Y |
connect() |
Y2 |
N3 |
recv() |
Y |
Y |
recvfrom() |
Y |
Y |
send() |
Y |
Y |
sendto() |
Y |
Y |
- Support for Winsock 2 was added in libsocket 0.7.4 beta 2, but didn't
work properly until beta 3.
- libsocket 0.7.4 beta 3 & later
- SOCK.VXD, used by the csock interface, does not yet allow non-blocking
connect() calls.
getsockopt() Compatibility1 |
getsockopt()
optname |
BSD sockets |
Winsock |
libsocket |
Winsock 1.x via WSOCK.VXD |
Winsock 2.x via SOCK.VXD2 |
SO_DEBUG |
Y |
Y |
Y |
N |
SO_REUSEADDR |
Y |
Y |
Y |
Y5 |
SO_KEEPALIVE |
Y |
Y |
Y |
N |
SO_DONTROUTE |
Y |
Y |
Y |
N |
SO_LINGER |
Y |
Y |
Y |
N |
SO_BROADCAST |
Y |
Y |
Y |
N |
SO_OOBINLINE |
Y |
Y |
Y |
N |
SO_SNDBUF |
Y |
Y |
Y |
Y5 |
SO_RCVBUF |
Y |
Y |
Y |
Y5 |
SO_SNDLOWAT |
Y |
N |
N |
Y5 |
SO_RCVLOWAT |
Y |
N |
N |
Y5 |
SO_SNDTIMEO |
Y |
N |
N |
Y5 |
SO_RCVTIMEO |
Y |
N |
N |
Y5 |
SO_TYPE |
Y |
Y |
Y |
N |
SO_ERROR |
Y |
Y |
Y |
N |
SO_ACCEPTCONN |
?3 |
Y |
Y |
N |
TCP_NODELAY |
?3 |
Y4 |
Y4 |
N |
IP_OPTIONS |
?3 |
N |
N |
N |
TCP_MAXSEG |
?3 |
N |
N |
N |
- All the options are at the SOL_SOCKET level, unless the level is
specified.
- SOCK.VXD does not provide a getsockopt() call.
- This option isn't present on Linux, so I don't know whether it's BSD or
not.
- This option is only at the IPPROTO_TCP level.
- This option is faked based on examination of the sources of SOCK.VXD.
setsockopt()
Compatibility1 |
setsockopt()
optname |
BSD sockets |
Winsock |
libsocket |
Winsock 1.x via WSOCK.VXD |
Winsock 2.x via SOCK.VXD2 |
SO_DEBUG |
Y |
Y |
Y |
N |
SO_REUSEADDR |
Y |
Y |
Y |
N |
SO_KEEPALIVE |
Y |
Y |
Y |
N |
SO_DONTROUTE |
Y |
Y |
Y |
N |
SO_LINGER |
Y |
Y |
Y |
N |
SO_BROADCAST |
Y |
Y |
Y |
N |
SO_OOBINLINE |
Y |
Y |
Y |
N |
SO_SNDBUF |
Y |
Y |
Y |
N |
SO_RCVBUF |
Y |
Y |
Y |
N |
SO_SNDLOWAT |
Y |
N |
N |
N |
SO_RCVLOWAT |
Y |
N |
N |
N |
SO_SNDTIMEO |
N |
N |
N |
N |
SO_RCVTIMEO |
N |
N |
N |
N |
SO_TYPE |
N |
N |
N |
N |
SO_ERROR |
N |
N |
N |
N |
SO_ACCEPTCONN |
?3 |
N |
N |
N |
TCP_NODELAY |
?3 |
Y4 |
Y4 |
N |
IP_OPTIONS |
?3 |
N |
N |
N |
TCP_MAXSEG |
?3 |
N |
N |
N |
- All the options are at the SOL_SOCKET level, unless the level is
specified.
- SOCK.VXD doesn't provide a setsocktopt() call.
- This option isn't present on Linux, so I don't know whether it's BSD or
not.
- This option is only at the IPPROTO_TCP level.
[Top]
Section 6: Miscellaneous Questions
Question 6.1: How do I find out if I have Winsock 2?
Look in the Windows system directory and see if there is a file there called
WSOCK2.VXD, e.g. do "dir c:\windows\system\wsock2.vxd".
If this file is present, then Winsock 2 has been installed.
Question 6.2: How can I uninstall Winsock 2?
It might not be possible to uninstall it, e.g. in the case of Windows '98.
If the operating system originally came with Winsock 1.1 then it is possible.
Some programs such as Sun's Java Software Development Kit (JDK) 1.1.5 install
Winsock 2 for you.
If Winsock 2 has been installed, then there will be a directory called
ws2bakup/ in your Windows directory. This directory contains a batch file
called ws2bakup.bat that restores the Winsock 1.1 files. I do not know
how ws2bakup.bat is supposed to be run, but I have found running it from
Windows and then from the Command Prompt after a reboot (press F8 and then
select the Command Prompt option when booting) seems to restore Winsock
1.1. The batch file restores registry settings (only works under Windows)
and copies the system files back (only works under DOS). I think if you
run it from the Command Prompt and then in Windows, it will require an
extra reboot as the Winsock 2 settings confuse Winsock 1.1 - this statement
maybe incorrect as it's a while since I did this.
Question 6.3: How can I install Winsock 2?
The simplest way of doing this is to obtain the Winsock 2 SDK for Windows
'95 from Microsoft's web site. This includes an install program that will
install Winsock 2 and create the back-up described above. I know this
works as I've been through the install-uninstall cycle several times.
Winsock 2 is also installed as part of the Dial-Up Networking 1.3
upgrade for Windows '95.
The following table describes the TCP/IP programs that Windows '95 comes
with. Most of these programs display help messages if run like so:
<program> /?. For more information, see the Windows '95
Resource Kit - this comes on the Windows '95 CD. These programs should also
be present under other versions of Windows.
Program | Description |
arp |
This can be used to display the IP address to Ethernet address
(hardware address) mappings, the ARP table, e.g. arp -a. |
ftp |
This is a text-mode FTP client, which is functional but basic. |
netstat |
This can be used to display the protocol statistics and status, such as
the state of TCP connections. |
ping |
This can be used to check other computers are connected/"up",
e.g. ping 192.168.0.23. This uses a protocol called
ICMP. |
route |
This can be used to display the routing table, which is used to route
IP packets to their destinations. Use route print to display the
routing table. |
telnet |
This is a telnet client, which is functional but basic. I use it all the
time as it's the fastest and simplest telnet client I've used. |
tracert |
tracert (or "traceroute") shows the route packets take to a
specified host. |
winipcfg |
This display current network settings, and was described in
question 3.2. It is called ipconfig on Windows NT. |
[Top]
[Top]
The layout of this page is by Indrek Mandre, and the content is by
Richard Dawe.
|