[Bug 9787] Warcraft3 Battle.net Doesn't work (Needs AcceptEx)
wine-bugs at winehq.org
wine-bugs at winehq.org
Fri Jul 4 18:10:56 CDT 2008
http://bugs.winehq.org/show_bug.cgi?id=9787
Scott Lindeneau <slindeneau at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |slindeneau at gmail.com
Raul <rcioldin at yahoo.com.br> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rcioldin at yahoo.com.br
Jon <blind.88 at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |blind.88 at gmail.com
--- Comment #206 from Scott Lindeneau <slindeneau at gmail.com> 2008-06-21 09:07:50 ---
I have been reviewing the patch that Andrey Turkin submitted 2008-01-08 and
would like to throw my 2 cents in. I haven't programmed in wine before, but I
wouldn't mind starting. Please tell me how/if/why I am wrong.
1) AcceptEx can return synchronously, but it doesn't matter if it does or not.
* This means that for simplicity it shouldn't.
2) The AcceptEx call has all of the information it needs when its called.
* All of the variables passed to AcceptEx must be initialized before it is
called.
* The AcceptEx function itself should only be a wrapper for a wine server
call to start an async accept, and then it should return.
3) Essentially AcceptEx is an easy way to ask the Operating System to start a
thread to listen on a socket, and to get rid of the thread automatically.
* We ask the wine server for an async accept (which should just be spawn a
thread, listen, and return after connect)
4) AcceptEx only adds the ability to read data on the socket before the
socket's error status changes from IO_PENDING to whatever.
* Why not add this functionality into the wine server's async accept?
--- Comment #207 from Raul <rcioldin at yahoo.com.br> 2008-06-24 13:32:33 ---
acceptex unnofficial patch in deb package please!
--- Comment #208 from Austin English <austinenglish at gmail.com> 2008-06-24 16:11:23 ---
(In reply to comment #207)
> acceptex unnofficial patch in deb package please!
>
Ask the maintainer to do that. Hacks are not accepted in WineHQ's codebase.
You could compile it yourself...
--- Comment #209 from Raul <rcioldin at yahoo.com.br> 2008-06-24 17:55:56 ---
after a long time downloading and compiling....
the "Disable completion port creation" patch didn't work...
I just have to get in my git dir and do
"patch -Np1 < mypatch.diff && tools/make_requests"???
--- Comment #210 from Scott Lindeneau <slindeneau at gmail.com> 2008-06-29 02:53:29 ---
(In reply to comment #209)
> after a long time downloading and compiling....
>
> the "Disable completion port creation" patch didn't work...
>
> I just have to get in my git dir and do
> "patch -Np1 < mypatch.diff && tools/make_requests"???
>
then you have to
>make depend
>make
>sudo make uninstall
>sudo make install
and type your password if prompted for the sudo.
--- Comment #211 from Jon <blind.88 at gmail.com> 2008-06-29 02:57:29 ---
(In reply to comment #0)
> Today's patches have caused Warcraft 3 battle.net to stop working. When
> connecting to Battle.net the "Connecting to Battle.net" box just idles
> indefinitely. No terminal output.
>
> I haven't run a regression yet so I don't know exactly which patch causes this.
>
I had this issue with wine 1.0 and the RC's. My work around was to click
battle.net then cancel (as it would get stuck) then click battle.net again, it
will work instantly the 2nd time.
--- Comment #212 from Peter <petoju at gmail.com> 2008-06-29 04:21:49 ---
(In reply to comment #211)
> (In reply to comment #0)
> > Today's patches have caused Warcraft 3 battle.net to stop working. When
> > connecting to Battle.net the "Connecting to Battle.net" box just idles
> > indefinitely. No terminal output.
> >
> > I haven't run a regression yet so I don't know exactly which patch causes this.
> >
>
> I had this issue with wine 1.0 and the RC's. My work around was to click
> battle.net then cancel (as it would get stuck) then click battle.net again, it
> will work instantly the 2nd time.
I have the same problem, clicking cancel helps, but this regression is in Wine
probably since 0.9.50 (I don't know exact Wine version).
(In reply to comment #210)
> (In reply to comment #209)
> > after a long time downloading and compiling....
> >
> > the "Disable completion port creation" patch didn't work...
> >
> > I just have to get in my git dir and do
> > "patch -Np1 < mypatch.diff && tools/make_requests"???
> >
>
> then you have to
> >make depend
> >make
> >sudo make uninstall
> >sudo make install
> and type your password if prompted for the sudo.
I'd try "sudo checkinstall" instead of sudo make install and sudo make
uninstall, because checkinstall creates package, that does NOT harm you package
system as "make" do.
--- Comment #213 from Andrey Turkin <andrey.turkin at gmail.com> 2008-06-29 06:19:29 ---
(In reply to comment #206)
> I have been reviewing the patch that Andrey Turkin submitted 2008-01-08 and
> would like to throw my 2 cents in. I haven't programmed in wine before, but I
> wouldn't mind starting. Please tell me how/if/why I am wrong.
>
> 1) AcceptEx can return synchronously, but it doesn't matter if it does or not.
> * This means that for simplicity it shouldn't.
I tried to cause AcceptEx to perform synchronously, but it always was failing
with IO_PENDING even when connection was available (on XP SP2). So AcceptEx
should not return synchronously for consistency with Windows.
> 2) The AcceptEx call has all of the information it needs when its called.
> * All of the variables passed to AcceptEx must be initialized before it is
> called.
> * The AcceptEx function itself should only be a wrapper for a wine server
> call to start an async accept, and then it should return.
AcceptEx should be wrapper for ws2_32-provided function (pointer can be
obtained via WSAIoctl with WSAID_ACCEPTEX guid), which probably should be a
wrapper for wineserver call.
>
> 3) Essentially AcceptEx is an easy way to ask the Operating System to start a
> thread to listen on a socket, and to get rid of the thread automatically.
> * We ask the wine server for an async accept (which should just be spawn a
> thread, listen, and return after connect)
Windows don't do this (NT kernel is fully asynchronous already); Wine don't
have to do this (asynchronous accept is available with POSIX sockets). I tried
to use these facilities, and here is main problem I faced with: wineserver
socket implementation is complicated and is tightly integrated with
asynchronous i/o part; latest patch posted here is faulty, and even with latest
changes I observed missed connections (Apache2 for Windows is quite good for
testing reliability).
Maybe distinct listener thread would be easier to implement AcceptEx properly,
I don't know.
>
> 4) AcceptEx only adds the ability to read data on the socket before the
> socket's error status changes from IO_PENDING to whatever.
> * Why not add this functionality into the wine server's async accept?
AcceptEx also gives you ability to "assign" socket to be used for new
connection, and more importantly AFAIK there is no async accept support in
wineserver at the moment.
--- Comment #214 from Martin Dengler <martin at martindengler.com> 2008-07-04 18:10:53 ---
I used to be able to play, but not host battle.net games with wine 1.0 without
any patches, and regressing to a wine pre-this-bug's-cause's-change would work
fine. After the 1.22 patch, I was able to play two or three games (one quite
long - 40 mins or so) and then the problems started: I would get disconnected
after about 5 minutes (once as long as 11 minutes) into the game. I have had
this happen about 5 times in a row now. So things are pretty unusable.
As for normal logs, I see:
fixme:mswsock:AcceptEx (listen=16796, accept=16800, 0x50200c0, 0, 32, 32,
0x33f948, 0x5020090), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16804, 0x5020148, 0, 32, 32,
0x33f948, 0x5020118), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16808, 0x50201d0, 0, 32, 32,
0x33f948, 0x50201a0), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16812, 0x5020258, 0, 32, 32,
0x33f948, 0x5020228), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16816, 0x50202e0, 0, 32, 32,
0x33f948, 0x50202b0), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16820, 0x5020368, 0, 32, 32,
0x33f948, 0x5020338), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16824, 0x50203f0, 0, 32, 32,
0x33f948, 0x50203c0), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16828, 0x5020478, 0, 32, 32,
0x33f948, 0x5020448), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16832, 0x5020500, 0, 32, 32,
0x33f948, 0x50204d0), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16836, 0x5020588, 0, 32, 32,
0x33f948, 0x5020558), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16840, 0x5020610, 0, 32, 32,
0x33f948, 0x50205e0), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16844, 0x5020698, 0, 32, 32,
0x33f948, 0x5020668), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16848, 0x5020720, 0, 32, 32,
0x33f948, 0x50206f0), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16852, 0x50207a8, 0, 32, 32,
0x33f948, 0x5020778), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16856, 0x5020830, 0, 32, 32,
0x33f948, 0x5020800), not implemented
fixme:mswsock:AcceptEx (listen=16796, accept=16860, 0x50208b8, 0, 32, 32,
0x33f948, 0x5020888), not implemented
fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub
fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub
fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub
fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub
fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub
fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub
fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub
fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub
fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub
fixme:imm:ImmAssociateContextEx (0x40034, (nil), 16): stub
I will look through this bug for the desired logging switches and see if I can
get anything more useful.
Martin
System info:
$ uname -a
Linux cree.xades.com 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q wine-core
wine-core-1.0-1.fc9.i386
$ cat /etc/fedora-release
Fedora release 9 (Sulphur)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the wine-bugs
mailing list