Mail Archives: djgpp/2000/10/04/11:45:53
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
- Raw text -