http://bugs.winehq.org/show_bug.cgi?id=8303
Austin English <austinenglish(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |REOPENED
Resolution|FIXED |
--- Comment #3 from Austin English <austinenglish(a)gmail.com> 2007-11-06 18:12:08 ---
Spoke too soon. Works if in a virtual desktop. Otherwise, no go. Reopening...
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8303
Austin English <austinenglish(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #2 from Austin English <austinenglish(a)gmail.com> 2007-11-06 18:10:21 ---
Closing fixed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8303
Austin English <austinenglish(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Austin English <austinenglish(a)gmail.com> 2007-11-06 18:10:08 ---
Works fine in wine 0.9.48. Still complains about that xml file though.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8030
Pariksheet Nanda <pnanda(a)stmarytx.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pnanda(a)stmarytx.edu
--- Comment #10 from Pariksheet Nanda <pnanda(a)stmarytx.edu> 2007-11-06 14:28:41 ---
I can also confirm this.
I applied the 1.4 patch from the EA websuite:
http://largedownloads.ea.com/pub/patches/NFS/carbon/
But it still gives the same error.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8513
--- Comment #14 from Kai Blin <blin(a)gmx.net> 2007-11-06 13:23:04 ---
(In reply to comment #13)
> umm, the problem is not in "BSD socket platform"/linux tcpip stack, the problem
> is in Wine lacking this functionality. Wine is already a middleman between apps
> and the kernel sockets, so what is stopping it from lying a little?
I have no intentions to implement that. If you feel like testing and
implementing it, have fun.
> How does it work under windows? Does it hijack the port unbinding it from the
> previous owner (and returns error)? or does the previous owner just stop
> receiving data until the new SO_REUSEADDR socket is released? What if a third
> app also uses SO_REUSEADDR and again takes port rom the previous one that used
> SO_REUSEADDR? :)
According to MSDN, the behaviour in that case is indeterminate, apart from
multicast sockets, where both apps will get the packet.
> I know that implementing it would look like a hack, but i suspect that its
> already a hack under windows from early tcpip implementation, and there are
> many applications using this flag (with your fix some of them will just fail to
> bind port since windows has no problem with this flag).
Most Windows apps I've seen that use SO_REUSEADDR actually assume a BSD
socket-like behaviour. The only one I know about that behaves differently is
the one this bug report initially was about.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8209
--- Comment #12 from EA Durbin <ead1234(a)hotmail.com> 2007-11-06 12:20:30 ---
with wine-0.9.48 I'm unable to accept the license agreement and proceed with
the installer
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8513
--- Comment #13 from rasz <citizenr(a)gmail.com> 2007-11-06 12:20:21 ---
>The initial problem is not fixable on a BSD
>socket platform.
umm, the problem is not in "BSD socket platform"/linux tcpip stack, the problem
is in Wine lacking this functionality. Wine is already a middleman between apps
and the kernel sockets, so what is stopping it from lying a little?
How does it work under windows? Does it hijack the port unbinding it from the
previous owner (and returns error)? or does the previous owner just stop
receiving data until the new SO_REUSEADDR socket is released? What if a third
app also uses SO_REUSEADDR and again takes port rom the previous one that used
SO_REUSEADDR? :)
I know that implementing it would look like a hack, but i suspect that its
already a hack under windows from early tcpip implementation, and there are
many applications using this flag (with your fix some of them will just fail to
bind port since windows has no problem with this flag).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.