Mail Archives: djgpp/2000/10/03/20:45:31
Hello.
Peter Remmers wrote:
>
> Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk> schrieb...
> > libsocket's Winsock 1.x support uses WSOCK.VXD to provide TCP/IP
> > networking to DOS programs under Windows. Unfortunately this method
> > doesn't work with Winsock 2. SOCK.VXD was the only way until recently
> > (that I know of) for interfacing DOS programs with Winsock 2. Now the
> > interface to Winsock 2's WSOCK2.VXD is known. Hopefully I can make
> > libsocket use it, to get decent networking with Winsock 2.
>
> 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. =)
> 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.
I may get round to adding WSOCK2.VXD support (*) to libsocket in December.
The idea of a couple of late nights hacking sounds tempting...
(*) = better (usable) Winsock 2 support
> Having multiple TCP/IP stacks on the same physical interface,
> as would be the case with packet drivers like NDIS3PKT, is probably
> the least desirable solution.
Agreed. NDIS3PKT isn't very easy to set up, from my limited experience of
it.
> My dream configuration would look like this:
> Just using libsocket, so I wouldn't have two executables.
> libsocket would load a "watt32.dxe" dynamically if it finds out, it's
> running in pure DOS and a packet driver is present, and load sock.vxd
> dynamically if running under windows.
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.
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)
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. ;)
> 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.
> And maybe we better discuss this in c.o.m.d
Yep, discussion shifted from comp.os.ms-windows.programmer.vxd.
As you can see, there's lots to do on libsocket. If anyone wants to help
out, please drop me a mail. Having said that, it helps to know that people
are testing it by using it.
Thanks, bye,
--
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]
- Raw text -