From: "Peter Remmers" <Peter DOT Remmers AT t-online DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: TCP/IP V86 API ?
Date: Wed, 4 Oct 2000 17:33:09 +0200
Organization: T-Online
Lines: 67
Message-ID: <8rfijo$fgd$16$1@news.t-online.com>
References: <8qli8q$jdh$10$1 AT news DOT t-online DOT com> <39D6F309 DOT C35B5453 AT phekda DOT freeserve DOT co DOT uk> <8r89to$6p$11$1 AT news DOT t-online DOT com> <39D8EC79 DOT 2BB0B32 AT phekda DOT freeserve DOT co DOT uk> <8rcfa4$9vk$16$1 AT news DOT t-online DOT com> <39DA26AD DOT 32119C6 AT phekda DOT freeserve DOT co DOT uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.t-online.com 970673592 16 15885 320094726121-0001 001004 15:33:12
X-Complaints-To: abuse AT t-online DOT de
X-Sender: 320094726121-0001 AT t-dialin DOT net
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk> schrieb...
> Hello.
>
> > If wsock2.vxd's DOS box API is that buggy (like described in
> > ws2dos.txt), I find sock.vxd in principle a much cleaner way - if it
> > weren't so buggy as well :-)
>
> Fortunately these bugs shouldn't affect libsocket, because it's not using
> 16-bit mode. So we should be OK. =)

Ah! Well then...

> > Of course using wsock2.vxd directly would be the most elegant way.
>
> Yep, that's the plan. Another advantage of this is that less code needs to
> be put into libsocket than e.g. for SOCK.VXD. libsocket contains code to
> emulate certain things that SOCK.VXD doesn't provide, e.g. socket options
> with getsockopt(). WSOCK.VXD and, no doubt, WSOCK2.VXD should support
> these things directly, making libsocket "just" a wrapper.

What exactly does SOCK.VXD not provide? Isn't it itself just a wrapper
for VTDI ?
Is VTDI lacking some features?

> I may get round to adding WSOCK2.VXD support (*) to libsocket in December.
> The idea of a couple of late nights hacking sounds tempting...

[...]

> I share this dream. I started to integrate Watt-32 into libsocket. I got
> to the point where it built and detected the packet driver, but I didn't
> get round to making it actually send data. I had a lack of time and (at
> that point) a network. I still have the branch in CVS somewhere, but I
> would start again from scratch, since Watt-32 has moved on.

That's a pity.
But even if you had managed it, watt-32 would have progressed independently
anyways, right?

> I don't think I'd implement it as a DXE either. I don't think the extra
> code would add that much to libsocket's library size. The resolver (DNS)

But you have DXE support on your to-to list!

> code accounts for a lot of its size. I have been thinking about switching
> to another resolver library (adns IIRC), but I have more important things
> to do with my time. ;)

Isn't that a contradiction to what you said above about the late night
hacking? :-)
But I must agree, direct wsock2.vxd support is a better candidate to put
on the high priority list...

> > Of course, sock.vxd would not need to be installed beforehand, it just
> > needs to be in the same directory as the executable...
>
> That can be added to the distributable "how to use libsocket in your
> programs" guide.

Where's this guide? Do you mean the "End-Users' Installation and
Configuration Guide" (redist/u-guide.txt) ?

Peter