FAQ version 1.0.5
Last updated: 12th June 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: Miscellaneous Questions
Section 7: Socket Programming Information
Section 8: 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.
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 if it's
a common problem.
[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 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. 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.
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.
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. However, this may not work the next version of libsocket, as
I intend to tidy up the include files. This is an interim solution.
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 in the meantime.
[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, 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 file!). Remember to edit hosts.eg and rename
it to hosts.
[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 6.1, question
6.2 and question 6.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 6.1,
question 6.2 and question 6.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]
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.
[Top]
Section 7: Socket Programming Information
This section has been moved to the libsocket
links page.
[Top]
Section 8: 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.
|