Mail Archives: djgpp-workers/2001/02/01/12:31:32
> work needs to be done. Now, to get recv() and send() to work, you need to
> patch WSOCK2.VXD, because there are some bugs that don't affect Windows
> programs (pfff). I don't know about anyone else, but I don't fancy asking
> end users to patch one of the key device drivers for their system!
Can't we use a dynamically loaded custom version of wsock2.vxd (i.e. patch
a copy of wsock2.vxd, distribute it with libsocket (under a different name)
and have libsocket dynamically load that vxd (the way it does for
coda.vxd))? There may be some legal issues, but IIRC patching software
for purposes of interoperability is protected by fair use, so as long as
the origin of the patched wsock2.vxd is clearly stated, there shouldn't be
a problem. Of course, IANAL.
> Tim, you may want to try Watt-32 instead. Windows users already have an
No point - CVS currently doesn't work in a SFN environment. I intend to
fix that someday - but that probably requires extensive work, and I just
don't have the time (I consider working on autoconf/automake more important
than adding SFN support to cvs).
> alternative in Cygwin's CVS or WinCVS (*). It's a nice piece of work and
> well established.
Yes, but it suffers from the EOL-convention problems my patched cvs
addresses (actually, WinCVS has some similar features, but they're not
quite perfect).
> It would be good for "pure" DOS users to have CVS access.
Indeed it would. <song>Someday, my SFN-enabled CVS(*) will come.</song>
(*) OK, this doesn't rhyme with 'prince'(**). It's not even similar.
So sue me.
(**) Those that don't get the reference: never mind. 'tis not important.
- Raw text -