Sender: richdawe AT bigfoot DOT com Message-ID: <36DB0027.FEBB1CCC@meridian22.net> Date: Mon, 01 Mar 1999 21:01:27 +0000 From: Richard Dawe X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.1 i586) MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com CC: Michael Callahan , "Peter J. Braam" Subject: Re: Integrating BSD socket networking into DJGPP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com > > 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/ ==============================================================================