FAQ version 1.1.0
Last updated: 18th August 1998
Copyright
libsocket Copyright 1997, 1998 by Indrek Mandre
libsocket Copyright 1997, 1998 by Richard
Dawe
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: Installation and Compilation
Section 4: Configuration
Section 5: Execution
Section 6: Programming with libsocket
Section 7: Miscellaneous Questions
Section 8: Socket Programming Information
Section 9: Other Networking Libraries
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.
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.
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").
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,
but it will require manual configuration, as it will not be able to obtain
networking information from the registry. It will require Microsoft's TCP/IP
stack, or another company's, to work properly, as TCP/IP support isn't
built into any version of Windows 3.x.
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 have only used it on Windows '95 with Service
Pack 1 installed - this is the original version. I do not know whether
it works with Operating System Releases 2 or 2.1 (OSR2 and OSR2.1), but
it should do.
However, if Winsock 2 is present then libsocket will not work - see
question 5.1, question 5.2,
question 7.1, question 7.2 and
question 7.3.
Question 2.4: Will libsocket work with Windows '98?
Windows '98 comes with Winsock 2 as standard. libsocket will not work -
see question 5.1 and question 5.2.
Question 2.5: Will libsocket work with Windows NT?
libsocket will not work under Windows NT and probably never will. Windows
NT is much more securely designed, so the backdoors libsocket uses to access
Winsock under Windows '95 simply aren't there. As with long filenames for
DOS programs in Windows NT DOS boxes, this is unlikely to change.
[Later: It looks like a driver to allow LFN access in NT DOS boxes has
emerged now. However, it's still unlikely that libsocket will ever work under
NT.]
Question 2.6: Will libsocket work with Linux?
libsocket shouldn't work with Linux, but should compile under it. After
all, DJGPP is a port of the GNU C compiler to DOS.
[Top]
Section 3: Installation and Compilation
Question 3.1: How should I rebuild libsocket?
Use the following set of commands at the DOS prompt to ensure that the
libsocket source tree is clean, that the dependencies are correct, to compile
all the library sources and, finally, to install the include files and
library into the DJGPP tree:
make distclean
make dep
make all
make install
If you wish to compile using long filenames, then use "make lfn" too.
If you haven't installed the man pages, you might like to "make
installman" too. If you'd like to rebuild the HTML versions of the
man pages, use "make htmldocs" (this will take a few minutes &
requires the source distribution).
To completely rebuild libsocket, you will need the standard set of ZIPs
required to compile C programs, the GNU Fileutils (see
question 3.3), man (from man12b.zip) and Perl (from
perl54b.zip, or ActiveState's
Perl for Win32). If you do not wish to rebuild the HTML versions of
the man pages, man and Perl are not required.
Question 3.2: When I do "make installman",
the man pages are installed into the wrong place. Why?
The destination for man pages is specified in Makefile.cfg. Change the
line "MAN_PLACE = ..." so that directory pointed to contains the
directory man/. E.g. if the man pages were to be installed into man/ off
mymandir/ below the DJGPP directory, you change the line to "MAN_PLACE
= $(DJDIR)/mymandir/".
Question 3.3: make complains that I don't have rm. Why?
The Makefiles rely on rm to remove files. rm is part of the GNU Fileutils,
which can be downloaded from the site where you got DJGPP. The file you
need is fil316b.zip.
Question 3.4: How do I compile a debugging version of
the library?
First of all, you will need the source distribution. After that, it depends
which version of the library you have:
Version 0.7.1 & later has Makefile targets to configure for
debugging. Use "make debug" to generate a Makefile.cfg with debugging
from the template file Make-cfg.in. Use "make nodebug" to turn this off.
After generating Makefile.cfg with either of these options, rebuild the
library using the procedure in question 3.1. Note that
the Makefile.cfg built with "make debug" passes the options "-g"
and "-DDEBUG" to gcc, i.e. the constant DEBUG is #define'd.
Version 0.7.0 & earlier needs Makefile.cfg to edited, and the option
"-g" to the "CFLAGS" line. Then rebuild the library as
described in question 3.1. If you add the option "-DDEBUG"
to the "CFLAGS" line, then the source will fail to compile without
editing. This can be fixed by editing the file r_opts.h, or res_options.h,
depending on the version, and wrapping it's #define of DEBUG in an #ifndef
... #endif, like so:
#ifndef DEBUG
#define DEBUG
#endif
This depends on which version of the library you have:
Version 0.7.1 & later has a template global settings
Makefile called Make-cfg.in, which should be edited to your requirements. Then
use "make debug" or "make nodebug" to create the global
settings Makefile, Makefile.cfg, with your settings.
Version 0.7.0 & earlier needs Makefile.cfg to be edited
directly.
If you haven't used the Makefile target "install" then no action is
required. Otherwise, it depends on which version of the library you have:
Version 0.7.3 (& later) has a Makefile target called
"uninstall". Use "make uninstall" to uninstall, or look at its
actions if you'd rather do it manually.
Version 0.7.2 & earlier require manual uninstallation.
The files to remove from the DJGPP directory are:
- include/netdb.h
- include/winsock.h
- include/ws.h
- include/sys/socket.h
- include/arpa/inet.h
- lib/libsocke.a or lib/libsocket.a
[Top]
Section 4: Configuration
Question 4.1: How can I find out my computer's IP address?
Question 4.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.
Question 4.3: I've run netsetup, but my libsocket programs
don't use the new settings. Why?
netsetup creates the files hosts.eg, networks.eg, host.conf and resolv.conf
in the setup/ directory. These have to be copied to the libsocket settings
directory. If you've set the LIBSOCKET environment variable to point to a
directory, then copy them there. Otherwise they should be copied to the Windows
directory (back up the current hosts and networks files!). Remember to edit
hosts.eg and networks.eg, if necessary, and rename them to hosts and
networks.
Both these connections use DHCP, which stands for Dynamic Host
Configuration Protocol. This allocates IP addresses dynamically
and allows them to be managed and assigned from a central point. It also allows
other sorts of information to given out, like DNS IP addresses. Thus, if a DNS
IP address is changed using DHCP, no manual reconfiguration of all the client
computers is necessary.
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 (fudge?):
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 4.1 and
question 4.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.
[Top]
Section 5: Execution
Question 5.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 5.2 below. libsocket currently does not
work with Winsock 2. If this is not the case, then there might be a bug
in your program ;) See question 7.1, question
7.2 and question 7.3 for more information.
Question 5.2: Why can't my program using libsocket create
sockets?
libsocket 0.7.0 & later will stop programs from creating sockets if Winsock
2 is present, to prevent the protection faults described in
question 5.1. See question 7.1,
question 7.2 and question 7.3 for more
information.
Question 5.3: Why does my program using libsocket stop
working?
If you have killed your program by closing the command prompt it is running
in, and then run the program in a new command prompt, then the program
may hang or fail to bind to sockets with error 98. It seems that killing
libsocket programs between one and four times leads to this problem. The
only solution appears to be to restart Windows, i.e. in order to re-initialise
WSOCK.VXD.
[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. I think this is a limitation of pre-2.0
Winsocks. I think Winsock 2.0 allows creation of any type of socket.
DJGPP includes definitions for ioctl()'s parameters in the include file
sys/io.h. However, they will not be defined if you include sys/io.h, as they
are enclosed in an '#if 0 ... #endif' pair. There are three possible
solutions to this problem:
Edit sys/io.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.
Wait for the next version of DJGPP, which will probably have better
support for ioctl() (see DJGPP's File System Extensions, FSEXT). This isn't
very helpful.
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.
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. libsocket provides 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.
[Top]
Section 7: Miscellaneous Questions
Question 7.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 7.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 7.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.
[Top]
Section 8: Socket Programming Information
This section has been moved to the libsocket
links page.
[Top]
Section 9: Other Networking Libraries
This section has been moved to the libsocket
links page.
[Top]
The layout of this page is by Indrek Mandre, and the content is by
Richard Dawe.
|