Mail Archives: djgpp-workers/1999/03/01/16:27:37
> > I was wondering what the position is on integrating something
> > like libsocket into DJGPP, in order to provide BSD socket networking.
>
> I'd vote for it, in general.
>
> But please tell more about the meaning of ``integrating''. Is there
> anything beyond providing a library against which DJGPP programs can
> be linked?
I was thinking of how to add it to the DJGPP source tree when I wrote the
word "integrating". Naturally there's all the header files that need to be
added, and the library, as you say.
Unfortunately the library is 1 character too long to fit in 8+3 -
libsocket.a. This will require some extra instructions. In libsocket there is
a special target for renaming the library (& others) as appropriate. How would
this be coped with in DJGPP?
> > 2. It needs lots of configuration.
> This could mean there's a need for a configuration tool.
> Can you explain what configuration is needed, and why ``lots'' of it?
You need name resolving code for doing DNS lookups. If you want anything more
complicated than just using the Windows 'hosts' file it means writing code to
contact DNS servers. libsocket contains the Linux resolving code. This
requires the files resolv.conf, host.conf, hosts that users of Linux know and
love.
As it happens I have written a configuration tool for libsocket that does
most of the hard work for you in creating resolv.conf, host.conf, hosts, etc.
libsocket has a problem in that it duplicates Windows name resolution code.
Thus, it needs to know DNS IP addresses, etc. It would be much better if it
could use Windows's name resolving code. This would eliminate the need for the
name resolution code, the configuration (since it's already done for Windows),
and would make the code much more compact.
Ideally, functions such as gethostbyname() would be part of SOCK.VXD.
> > 4. It comprises a lot of code.
>
> How much is ``a lot''?
~1.6MB, including Makefiles. 1/4 of this is the Linux resolver code, another
1/4 is the Winsock code, including registry access, another 1/4 is the header
files.
> Are we sure SOCK.VXD will always work? Can some future Windows
> version break it?
SOCK.VXD uses the Transport Driver Interface, which has been in Windows since
version 3.11 for Workgroups. It should work with WfWg 3.11, Win95, Win98. NT
is an entirely different matter. If no future version of Windows is based on
Win98, then it will be broken.
It might be possible to add NT support via a "DOS virtual device".
> And why does it allow a cleaner interface? Is it simply because its
> interface is documented, as opposed to Winsock's?
We know the interface, because we have the source. It's cleaner because it's
easier to use from DJGPP. All the parameters are passed as registers, whereas
Winsock makes you use structures. It can all be coded as inline assembly.
The interface provided by SOCK.VXD isn't as complete as Winsock's. Code using
SOCK.VXD works on more versions of Windows than that using Winsock, i.e. with
all versions of Winsock. This is better IMHO.
Another question - is the DJGPP 2.02 in the v2/ directory actually the final
release of 2.02, or is it a beta?
--
==============================================================================
Rich Dawe - 4th-year MSci Physicist @ Bristol University, UK
richdawe AT bigfoot DOT com, http://www.bigfoot.com/~richdawe/
==============================================================================
- Raw text -