[Bug 9787] Warcraft3 Battle.net Doesn't work (Needs AcceptEx)
wine-bugs at winehq.org
wine-bugs at winehq.org
Mon Jul 6 14:06:33 CDT 2009
http://bugs.winehq.org/show_bug.cgi?id=9787
Michał Kozal <panaut0lordv at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |panaut0lordv at gmail.com
DanielSjoholm <steelside at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #20299|Hopefully updated for |Hopefully updated for
description|1.1.18 |1.1.18
| |Typo, won't build.
Attachment #20299|0 |1
is obsolete| |
UncleOwen <anakin.skyw at gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anakin.skyw at gmx.de
Vitaliy Margolen <vitaliy at kievinfo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hardkaare at gmail.com
Daniel Rhodes-Mumby <daniel.rhodes.mumby at googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |daniel.rhodes.mumby at googlem
| |ail.com
Christoph Haag <therealchris at hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |therealchris at hotmail.com
Austin English <austinenglish at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|austinenglish at gmail.com |
Rob Wilson <cinzento007 at yahoo.com.br> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |cinzento007 at yahoo.com.br
Matej Spindler <matej.spindler at auspuh.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |matej.spindler at auspuh.com
Rob Wilson <cinzento007 at yahoo.com.br> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #20615|0 |1
is obsolete| |
Austin English <austinenglish at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |whellmundv at gmail.com
Nephyrin zey <Nephyrin at nephyrin.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Nephyrin at nephyrin.net
Stev47 <stephan at ehilb.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stephan at ehilb.de
Rob Wilson <cinzento007 at yahoo.com.br> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #20616|0 |1
is obsolete| |
Attachment #20617|0 |1
is obsolete| |
Matt Callaghan <fermulator at sympatico.ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fermulator at sympatico.ca
snakt at hotmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |snakt at hotmail.com
Mike Kaplinskiy <mike.kaplinskiy at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mike.kaplinskiy at gmail.com
Fernando <fernandocarvalho1987 at hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fernandocarvalho1987 at hotmai
| |l.com
Robert Förster <Dessa at gmake.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Dessa at gmake.de
--- Comment #350 from Nicky <nheart at gmail.com> 2009-03-28 07:40:01 ---
Could I request an AcceptEx patch that correctly applies to 1.1.18?
--- Comment #351 from Michał Kozal <panaut0lordv at gmail.com> 2009-03-29 14:24:48 ---
(In reply to comment #350)
> Could I request an AcceptEx patch that correctly applies to 1.1.18?
>
1.1.12 patch applies just fine, you've to use also
http://bugs.winehq.org/attachment.cgi?id=20103 for wc3 1.23
--- Comment #352 from DanielSjoholm <steelside at gmail.com> 2009-04-05 07:45:12 ---
(In reply to comment #351)
> (In reply to comment #350)
> > Could I request an AcceptEx patch that correctly applies to 1.1.18?
> >
>
> 1.1.12 patch applies just fine, you've to use also
> http://bugs.winehq.org/attachment.cgi?id=20103 for wc3 1.23
>
It doesn't work for me (acceptex patch) for 1.1.18... this is with fuzz=0 thou
(haven't tried without it), but needs a fix to work moar smooth. (Worked
flawless for .15 with the exact same setup)
1 out of 6 hunks FAILED -- saving rejects to file server/async.c.rej
1 out of 2 hunks FAILED -- saving rejects to file server/file.h.rej
--- Comment #353 from DanielSjoholm <steelside at gmail.com> 2009-04-05 08:18:38 ---
Created an attachment (id=20299)
--> (http://bugs.winehq.org/attachment.cgi?id=20299)
Hopefully updated for 1.1.18
This is the 1.1.12 patch modified to work for 1.1.18.
It went through here, so I hope it's good.
--- Comment #354 from DanielSjoholm <steelside at gmail.com> 2009-04-05 08:53:46 ---
(From update of attachment 20299)
Oops i rushed posting it here, this patch has a typo in it. This time I'll
compile it first, so uploading a new one in a moment.
--- Comment #355 from DanielSjoholm <steelside at gmail.com> 2009-04-05 10:24:47 ---
Created an attachment (id=20300)
--> (http://bugs.winehq.org/attachment.cgi?id=20300)
Working patch for 1.1.18
Sorry about the mailspam..
Anyway, this one got no hunks rejected, compiles fine, hosting worked.
Same procedure as for the 1.1.12 patch is required for compiling.
Also remember to patch with the secur32 thing ^, as else the 1.23 patch will
have wc3 crashing in under a minute in any chat channel.
--- Comment #356 from Vitaliy Margolen <vitaliy at kievinfo.com> 2009-04-07 09:05:11 ---
*** Bug 17951 has been marked as a duplicate of this bug. ***
--- Comment #357 from Christoph Haag <therealchris at hotmail.com> 2009-04-09 04:24:43 ---
Created an attachment (id=20349)
--> (http://bugs.winehq.org/attachment.cgi?id=20349)
Buildlog: AcceptEx Patch does not work for wine 1.1.8
(In reply to comment #355)
> Created an attachment (id=20300)
--> (http://bugs.winehq.org/attachment.cgi?id=20300) [details]
> Working patch for 1.1.18
> Anyway, this one got no hunks rejected, compiles fine, hosting worked.
> Same procedure as for the 1.1.12 patch is required for compiling.
The patch does not work here on Archlinux.
--- Comment #358 from Daniel Rhodes-Mumby <daniel.rhodes.mumby at googlemail.com> 2009-04-11 19:16:13 ---
(In reply to comment #357)
> Created an attachment (id=20349)
--> (http://bugs.winehq.org/attachment.cgi?id=20349) [details]
> Buildlog: AcceptEx Patch does not work for wine 1.1.8
>
> (In reply to comment #355)
> > Created an attachment (id=20300)
--> (http://bugs.winehq.org/attachment.cgi?id=20300) [details] [details]
> > Working patch for 1.1.18
>
> > Anyway, this one got no hunks rejected, compiles fine, hosting worked.
> > Same procedure as for the 1.1.12 patch is required for compiling.
>
> The patch does not work here on Archlinux.
>
By the looks of things you didn't run tools/make_request beforehand.
I had the same problem, read through the thread a bit and then ran the script
before calling make again. It compiled fine that time.
--- Comment #359 from Christoph Haag <therealchris at hotmail.com> 2009-04-12 06:48:03 ---
(In reply to comment #358)
> (In reply to comment #357)
> > Created an attachment (id=20349)
--> (http://bugs.winehq.org/attachment.cgi?id=20349) [details] [details]
> > Buildlog: AcceptEx Patch does not work for wine 1.1.8
> >
> > The patch does not work here on Archlinux.
> >
> By the looks of things you didn't run tools/make_request beforehand.
> I had the same problem, read through the thread a bit and then ran the script
> before calling make again. It compiled fine that time.
Yes, the building procedure was:
> build() {
> cd $srcdir/$pkgname-$pkgver
> patch -p1 < $startdir/acceptex-1.1.18.patch
> ./configure --prefix=/usr --sysconfdir=/etc --with-x
> make depend || return 1
> make || return 1
> make prefix=$pkgdir/usr install || return 1
> mkdir -p $pkgdir/etc/wine
> }
After adding
> tools/make_requests
(the file is called make_requests with s at the end) after the configure and
> patch -p1 < $startdir/0001-secur32-Disable-schannel-InitializeSecurityContextW.patch
before (sec32 bug), it seems to compile fine. Strange, in the last wine version
it compiled with the patch without seperately running make_requests.
--- Comment #360 from Rob Wilson <cinzento007 at yahoo.com.br> 2009-04-15 17:14:43 ---
Could anyone make a step-by-step tutorial to install this AccpetEx patch?
I couldn't even found it to download, and I would be really glad if you could
help me here.
Thanks.
--- Comment #361 from Lukáš Krejza <gryffus at hkfree.org> 2009-04-19 06:03:48 ---
(In reply to comment #326)
> Ok so lets hope he will find some time for this... Thanx for the info...
>
> Gfs
>
Does anyone already know the Alexandre's opinion? What exactly is a problem
with this patch that it cannot be inculded?
If there is no other way to implement this - it means that it will not be
implemented??
--- Comment #362 from Rob Wilson <cinzento007 at yahoo.com.br> 2009-04-22 17:30:47 ---
Created an attachment (id=20615)
--> (http://bugs.winehq.org/attachment.cgi?id=20615)
Error compiling AcceptEx patched 1.1.18 version
--- Comment #363 from Rob Wilson <cinzento007 at yahoo.com.br> 2009-04-22 17:32:45 ---
Created an attachment (id=20616)
--> (http://bugs.winehq.org/attachment.cgi?id=20616)
Error compiling AcceptEx patched 1.1.18 version
--- Comment #364 from Rob Wilson <cinzento007 at yahoo.com.br> 2009-04-22 17:32:55 ---
Created an attachment (id=20617)
--> (http://bugs.winehq.org/attachment.cgi?id=20617)
Error compiling AcceptEx patched 1.1.18 version
--- Comment #365 from Rob Wilson <cinzento007 at yahoo.com.br> 2009-04-23 18:06:17 ---
I've applied the patchs (acceptex-1.1.18.patch and
0001-secur32-Disable-schannel-InitializeSecurityContextW.patch), compiled and
installed wine 1.1.18. Now chat and hosting works perfectly (they didn't with
no-patched version). But I still can't play Bnet games. Once the map finishes
loading and the game screen appear, the "You have been disconnected." message
appears.
Does anyone have any idea about wich problem can it be? How can I fix this?
--- Comment #366 from Rob Wilson <cinzento007 at yahoo.com.br> 2009-04-23 18:11:33 ---
I've applied the patchs (acceptex-1.1.18.patch and
0001-secur32-Disable-schannel-InitializeSecurityContextW.patch), compiled and
installed wine 1.1.18. Now chat and hosting works perfectly (they didn't with
no-patched version). But I still can't play Bnet games. Once the map finishes
loading and the game screen appear, the "You have been disconnected." message
appears.
Does anyone have any idea about wich problem can it be? How can I fix this?(In
reply to comment #365)
> I've applied the patchs (acceptex-1.1.18.patch and
> 0001-secur32-Disable-schannel-InitializeSecurityContextW.patch), compiled and
> installed wine 1.1.18. Now chat and hosting works perfectly (they didn't with
> no-patched version). But I still can't play Bnet games. Once the map finishes
> loading and the game screen appear, the "You have been disconnected." message
> appears.
>
> Does anyone have any idea about wich problem can it be? How can I fix this?
>
I've forgot to say: custom game works perfectly. I'm having problems just with
ladder games.
--- Comment #367 from Rob Wilson <cinzento007 at yahoo.com.br> 2009-04-23 18:32:58 ---
I've solved my problem. It was just some ip ports that I had to open.
--- Comment #368 from Vitaliy Margolen <vitaliy at kievinfo.com> 2009-04-23 20:19:14 ---
(In reply to comment #367)
Rob Wilson <cinzento007 at yahoo.com.br>
Would you stop spamming bugzilla! Use forums to ask user questions. You posted
dozen comments that do not add any additional information to the bug.
If you need help with using your system (which includes compiler) consult
manual for it.
--- Comment #369 from Austin English <austinenglish at gmail.com> 2009-04-26 20:55:05 ---
*** Bug 15794 has been marked as a duplicate of this bug. ***
--- Comment #370 from Nephyrin zey <Nephyrin at nephyrin.net> 2009-06-03 05:34:42 ---
So, looking to play Warcraft III in wine, i booted it up to immediately
encounter massive battle.net issues. After looking up these bugs, i did the
following:
- Recompiled wine (1.1.22) with gnutls
- applied "Disable schannel InitializeSecurityContextW" from bug 17809
- applied the most recent acceptex 1.1.18 patch from this bug (9787) (it does
work on .22, just need to rerun make_requests)
After doing this, warcraft III works flawlessly. I started battle.net and
played and hosted several games with no issue. I did get a 'disconnected' error
immediately after signing in the first time, but was unable to reproduce on
subsequent logins. Warcraft III would be nearly platinum status if these
patches (or more appropriate fixes) were mainline.
The only issue i encountered, other than the one disconnect, was that
de-focusing the window and refocusing causes white textures. Emulate virtual
desktop works around this.
Oh and in OpenGL mode, solid 60FPS.
--- Comment #371 from Matt Callaghan <fermulator at sympatico.ca> 2009-06-15 22:27:57 ---
I'm also very interested to know why this patch isn't included in the main wine
branch. Forcing users to compile wine and apply the patch manually is a little
ridiculous.
What do we need to do in order to see this in future wine versions?
--- Comment #372 from Austin English <austinenglish at gmail.com> 2009-06-15 22:41:55 ---
(In reply to comment #371)
> I'm also very interested to know why this patch isn't included in the main wine
> branch. Forcing users to compile wine and apply the patch manually is a little
> ridiculous.
>
> What do we need to do in order to see this in future wine versions?
This has been answered multiple times in the comments. No need to add new
comments to ask why.
--- Comment #373 from snakt at hotmail.com 2009-06-22 07:50:41 ---
Compiles sucsessfully into 1.0.24 though random game closures do occour, i have
not yet managed to catch the output from one of these events.
--- Comment #374 from Mike Kaplinskiy <mike.kaplinskiy at gmail.com> 2009-06-22 19:08:51 ---
I have been looking at the architecture of wineserver in the hopes of seeing
the reason that Alexandre might have not liked the approach taken. The
explanation as far as I can see it is that the extra locator parameter is
superfluous. The current wineserver architecture seems to support a "waiting
until further notice (accepted)" by adding an event at the top of the socket's
read/write queue. This way since it is the top request and is not removed until
the socket is connected, no other sync/async ops can get through (NOTE: not
sure about sync ops, but Scott's patch doesn't make special cases for it
AFAICT).
Scott - you have experience with this; does this approach seem feasible? Or is
there something I'm missing? If you'd like, I can try to come up with some sort
of alpha patch to show you what I'm talking about (switching accept_socket
request to only async/adding a block param & putting wait event on the accept's
r/w queues).
--- Comment #375 from Scott Lindeneau <slindeneau at gmail.com> 2009-06-29 14:44:17 ---
Mike, Thanks for taking the time to look through the patch. Points to note:
The locator tags are to remove asynchronous commands from the async queue of a
listening socket when the accepting socket socket is closed or deleted (and
vice versa). The locator tags are not specifically used to deal with connecting
sockets. It is to handle the situation when sockets are closed before
connections occur. If an AcceptEx call is made with 10 accepting sockets on one
listening socket(as is the case of war3) and the accepting sockets are closed
(as is the case when you join a game and leave before the game starts) then the
accepting sockets are closed by the game, but the listening socket is not
closed. In this case we must remove the closed accepting sockets async commands
from the listening sockets async queue. If we do not remove these async
commands the wineserver will attempt to use those closed sockets to connect to,
which results in unpredictable behavior.
If we didn't have to worry about this case, we wouldn't need the locator tags.
In fact, my first several versions didn't handle this case (and caused the
wineserver and warcraft3 to lockup and crash if you didn't have 10 people join
every game you hosted or joined).
The reason, I think, that the patch was rejected was for the modification I
made to the async notification logic. Currently, the async notify will only
notify the first async command on the list that a new event has occurred. If
that async command is busy(i.e. is currently processing something), the new
notification will be ignored. The wineserver is supposed to be implemented such
that once the currently processing async command finishes, the next async
command on the queue is notified (and will check for any new notifications, in
this case incoming connections.), however, I cannot make this work. I was
unable to make the finishing async command notify the next async command. To
get around this problem I changed the behavior async commands are notified.
Instead of ignoring the notification if an async command is busy, it will
notify the next non-busy async command, if one exists.
This modification is only relevant to the following situation (for AcceptEx):
Two(or more) incoming connections happen simultaneously or very very very close
together. Without the modification, the second incoming connection will be
ignored, because the async command to handle to second incoming connection is
never notified(without the modification). You would almost never see this
situation in warcraft3, and is only apparent in the test code I submitted.
Hope this helps.
--- Comment #376 from Fernando <fernandocarvalho1987 at hotmail.com> 2009-07-04 07:34:44 ---
Could someone send me a tutorial, with full detailed explanation, that helps me
play Warcraft using Garena?
--- Comment #377 from Mike Kaplinskiy <mike.kaplinskiy at gmail.com> 2009-07-04 23:38:31 ---
Created an attachment (id=22193)
--> (http://bugs.winehq.org/attachment.cgi?id=22193)
Less intrusive
Thanks Scott, that helped a lot. I'm sorry to say that since I don't check
bugzilla pages too often (and I was expecting an email from your comment, which
never came), I started working on my own less intrusive solution. Sorry about
the mixup.
The attached is my progress so far (as you can tell the parts in winsock are
completely yours). I don't think it works (not completely sure), since it fails
one of your conformance tests (you sent it at...some point? overlapped_server)
However with this approach, we no longer need: async changes (the fix is at
sock_get_poll_events), register_async_l (keeps an async * in the accepting
socket and then cancels it on destroy. Sadly this does require another request
type: register_accept_async :-\). Also, assuming windows returns deferred
sockets through acceptex, we are ready to handle that as well.
Regardless, we're going to need a bulk of conformance tests to see how windows
handles some tricky cases. In the case that we're lucky and windows doesn't
require any weirdness with regards to acceptex & CF_DEFER, we won't need any
changes other than to sock.c in the server.
We also need some major checks before we start all the async accept business,
since the socket has to be unbound, unconnected, and furthermore, we cannot
queue events on the accept socket while it has not been accepted (needs
checks...somewhere? maybe remove FD_READ|FD_WRITE on the status?)
Again, sorry for the mixup.
Mike.
--
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