Re: bogus patch to bind() dlls/winsock/socket.c (request removal)

[Ivan Leo Murray-Smith]

> With this change, we can use the 6.3 version of Quicktime
> to see streamed video from Wineconf...
> This would break Grand Prix Legends and Nascar 2002 (Thats why the patch was
> written in the first place), maybe you should contact the author of the patch, a
> proper fix would be better, why should we chose between 2 games and quicktime?
> It should be possible to run all these apps.

Ivan.

bogus patch to bind() dlls/winsock/socket.c (request removal)

[Daniel Kegel]

Ivan Leo Murray-Smith wrote:
> > With this change, we can use the 6.3 version of Quicktime
> > to see streamed video from Wineconf...
>
> This would break Grand Prix Legends and Nascar 2002 (Thats why the patch was
> written in the first place), maybe you should contact the author of the patch, a
> proper fix would be better, why should we chose between 2 games and quicktime?
> It should be possible to run all these apps.

Sounds like somebody needs to look at Stevens and see if it's
really ok to bind multiple times, and if so, whether this
is a bug in Linux.  I might, but then again, Alex might have
already chewed up that page :-)
- Dan

bogus patch to bind() dlls/winsock/socket.c (request removal)

[Jeremy White]

Ivan Leo Murray-Smith wrote:
> > With this change, we can use the 6.3 version of Quicktime
> > to see streamed video from Wineconf...
>
> This would break Grand Prix Legends and Nascar 2002 (Thats why the patch was
> written in the first place), maybe you should contact the author of the patch, a
> proper fix would be better, why should we chose between 2 games and quicktime?
> It should be possible to run all these apps.

Jeremy Shaw already argued that the patch was incorrect, and
I am near dead certain that he is right.

It's been years since I was a Stevens expert, but there was a day
when I was, and my gut reaction to that patch was one of
shuddering horror.  In fact, I really should
argue for the complete reversal of the patch until a regression
test can conclusively prove that Window misbehaves in such
a horrid way (i.e. auto doing a reuseaddr and not using DONTROUTE).

If Windows *does* allow you to double bind an address, it can
only be the case that it does so in limited circumstances,
and we should implement those limited circumstances, rather
than applying a shotgun to the problem.

Cheers,

Jer

bogus patch to bind() dlls/winsock/socket.c (request removal)

[Alexandre Julliard]

Jeremy White <jwhite(a)codeweavers.com> writes:
> It's been years since I was a Stevens expert, but there was a day
> when I was, and my gut reaction to that patch was one of
> shuddering horror.  In fact, I really should
> argue for the complete reversal of the patch until a regression
> test can conclusively prove that Window misbehaves in such
> a horrid way (i.e. auto doing a reuseaddr and not using DONTROUTE).

Well, the patch apparently helps in some cases and hurts in others, so
the only way to decide is to write a test and determine what the exact
behavior is under Windows. I agree the current behavior looks wrong,
but that doesn't mean anything when dealing with Microsoft code...

-- 
Alexandre Julliard
julliard(a)winehq.com

bogus patch to bind() dlls/winsock/socket.c (request removal)

[Jeremy White]

> Well, the patch apparently helps in some cases and hurts in others, so
> the only way to decide is to write a test and determine what the exact
> behavior is under Windows. I agree the current behavior looks wrong,
> but that doesn't mean anything when dealing with Microsoft code...

A quick foo.c shows that even Windows 98 respects the lack
of the REUSEADDR flag in meaningful ways; the attached
socktest.c shows that binding the same port twice fails
on the second request, but emulating the current Wine
behavior (which can be done by turning on parm #4)
causes a success.

As such, Wine is badly broken; any algorithm that relies
on iterating through possible ports and doing something
meaningful when a port is already in use will be utterly
useless with the current code.

I'll go ahead and see if I can't figure out how to
modify the regression tests to properly test for this.

Cheers,

Jer