On 17 Apr 2002, Alexandre Julliard wrote:
> Martin Wilck <[EMAIL PROTECTED]> writes:
>
> > PATCH: accept-deferred.diff
> >
> > If a connection request is deferred in a call to WSAAccept(),
> > a subsequent accept()/WSAAccept() call must return the
> > previously deferred connection rather than a
Martin Wilck <[EMAIL PROTECTED]> writes:
> PATCH: accept-deferred.diff
>
> If a connection request is deferred in a call to WSAAccept(),
> a subsequent accept()/WSAAccept() call must return the
> previously deferred connection rather than a new one.
You cannot store a handle to the deferred soc
On April 15, 2002 09:38 am, Martin Wilck wrote:
> On Fri, 12 Apr 2002, Dimitrie O. Paun wrote:
> > > +if ( lpCallerData || lpCalleeData || lpSQOS || lpGQOS )
> > > +WARN ("unsupported parameters!");
> >
> >
> > Shouldn't this be a FIXME instead?
>
> I don't think so - t
On Fri, 12 Apr 2002, Dimitrie O. Paun wrote:
> > +if ( lpCallerData || lpCalleeData || lpSQOS || lpGQOS )
> > +WARN ("unsupported parameters!");
>
> Shouldn't this be a FIXME instead?
I don't think so - there is little to fix on the part of wine.
AFAICS the Linux netw
On April 12, 2002 11:20 am, Martin Wilck wrote:
> /***
> + * WSAConnect (WS2_32.30)
> + */
> +int WINAPI WSAConnect ( SOCKET s, const struct WS_sockaddr* name, int
> namelen, +LPWS
PATCH: accept-deferred.diff
If a connection request is deferred in a call to WSAAccept(),
a subsequent accept()/WSAAccept() call must return the
previously deferred connection rather than a new one.
The current CVS implementation of WSAAccept is wrong in this respect.
This patch fixes this. Fur
