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.
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
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
Jeremy White jwhite@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...
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
-
Alexandre Julliard -
Daniel Kegel -
Ivan Leo Murray-Smith -
Jeremy White