http://bugs.winehq.org/show_bug.cgi?id=9787
Michał Kozal panaut0lordv@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |panaut0lordv@gmail.com
DanielSjoholm steelside@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@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anakin.skyw@gmx.de
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hardkaare@gmail.com
Daniel Rhodes-Mumby daniel.rhodes.mumby@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.rhodes.mumby@googlem | |ail.com
Christoph Haag therealchris@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |therealchris@hotmail.com
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|austinenglish@gmail.com |
Rob Wilson cinzento007@yahoo.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cinzento007@yahoo.com.br
Matej Spindler matej.spindler@auspuh.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matej.spindler@auspuh.com
Rob Wilson cinzento007@yahoo.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #20615|0 |1 is obsolete| |
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |whellmundv@gmail.com
Nephyrin zey Nephyrin@nephyrin.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Nephyrin@nephyrin.net
Stev47 stephan@ehilb.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stephan@ehilb.de
Rob Wilson cinzento007@yahoo.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #20616|0 |1 is obsolete| | Attachment #20617|0 |1 is obsolete| |
Matt Callaghan fermulator@sympatico.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fermulator@sympatico.ca
snakt@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |snakt@hotmail.com
Mike Kaplinskiy mike.kaplinskiy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike.kaplinskiy@gmail.com
Fernando fernandocarvalho1987@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fernandocarvalho1987@hotmai | |l.com
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
Nicky nheart@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nheart@gmail.com
Mike Kaplinskiy mike.kaplinskiy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22193|0 |1 is obsolete| |
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22759|application/octet-stream |text/plain mime type| |
Nicky nheart@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22700|0 |1 is obsolete| |
Mike Kaplinskiy mike.kaplinskiy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22621|0 |1 is obsolete| | Attachment #23096|0 |1 is obsolete| |
Daniel sersmicro@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sersmicro@gmail.com
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
--- Comment #350 from Nicky nheart@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@kievinfo.com 2009-04-23 20:19:14 --- (In reply to comment #367) Rob Wilson cinzento007@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@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@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@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@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@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@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@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@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@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.
--- Comment #378 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-07-13 18:19:48 --- Would anyone with WC3 mind testing the patches at http://osdir.com/ml/wine-devel/2009-07/msg00275.html ?
--- Comment #379 from Nicky nheart@gmail.com 2009-07-18 04:52:44 --- Now compiling the latest git with your patches (already have one compiled with scott's patches, will test some games with it). Is there anything you expect not to work as it should?
--- Comment #380 from Nicky nheart@gmail.com 2009-07-18 06:51:38 --- Created an attachment (id=22428) --> (http://bugs.winehq.org/attachment.cgi?id=22428) Console output from war3.
Hosted 2 games. The first game noone joined, the second (dota) got instantly full. 3 people lagged out from game (But I guess they just left). However the console output is quite long, so I attach it to you.
--- Comment #381 from Nicky nheart@gmail.com 2009-07-19 09:30:20 --- Created an attachment (id=22453) --> (http://bugs.winehq.org/attachment.cgi?id=22453) Console output #2
So... PLayed several games... Got disconected from 2 of the games (as if I got kicked... Suddenly "You have been disconected" appeared. However after that I was unable to host a game. Wheneever I tried to create a game I received message "Your connection to Battle.net has been lost." and I had to reconnect to battle.net, however I was still unable to host a game (same error). Should I use any WINEDEBUG channels in my future attachments?
--- Comment #382 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-07-25 22:52:03 --- Created an attachment (id=22621) --> (http://bugs.winehq.org/attachment.cgi?id=22621) Set as of 7/25/2009
(In reply to comment #381)
Created an attachment (id=22453)
--> (http://bugs.winehq.org/attachment.cgi?id=22453) [details]
Console output #2
So... PLayed several games... Got disconected from 2 of the games (as if I got kicked... Suddenly "You have been disconected" appeared. However after that I was unable to host a game. Wheneever I tried to create a game I received message "Your connection to Battle.net has been lost." and I had to reconnect to battle.net, however I was still unable to host a game (same error). Should I use any WINEDEBUG channels in my future attachments?
sorry for the long lack of a response. Bugzilla doesn't send e-mails when you add comments on this bug. If you could, next time send me an e-mail (you can forgo posting here).
There may have been a few problems with that patch. The attached is the latest one I'm trying to get checked in.
As for log channels, I suggest first testing without them, but if there is an obvious problem (like the one you're describing about not being able to host), turn on winsock logging. It will probably slow down your game significantly.
Thanks for testing.
--- Comment #383 from Nicky nheart@gmail.com 2009-07-30 07:04:04 --- Created an attachment (id=22700) --> (http://bugs.winehq.org/attachment.cgi?id=22700) WINEDEBUG=+winsock
Okay... I've been testing your newest patch for all morning and there are no errors. I've been hosting games, joining games, playing ladder... flawless work so far... Without WINEDEBUG=+winsock there's not console output regarding winsock/acceptex. With WINEDEBUG=+winsock the game doesn't slow down at all and the output is only informative, no errors whatsoever... I attach it to you, nevertheless. IMO this patch works better than Scotts' because players were able to download games simultaneously (while with Scott' implementation players were queued and had to wait each other to finish downloading). And there's no erroneous console output (like noted in comment 269 and comment 282)
--- Comment #384 from Nicky nheart@gmail.com 2009-08-01 06:20:45 --- Created an attachment (id=22759) --> (http://bugs.winehq.org/attachment.cgi?id=22759) Console output after getting disconected.
Hi, Sadly, I encountered the error I reported with the previous patch. At some point while playing I suddenly got disconected. Looked at the console and saw the familiar winsock related fixmes. The second part of those fixmes was triggered when I tried to host a game. When I did this, I received a message "Your connection to battle.net has been lost" error and I was unable to host until game restart. Unfortunately I hadn't enabled winsock debug channel and I can't give you any more detailed info. I will countinue playing always with WINEDEBUG=+winsock, but I have no idea when this error is going to appear again (as it would seem it is much less common than with your previous patch). Regards Nicky
--- Comment #385 from Nicky nheart@gmail.com 2009-08-10 14:15:01 --- Created an attachment (id=22978) --> (http://bugs.winehq.org/attachment.cgi?id=22978) WINEDEBUG=+winsock receiving an error.
Mike, Fortunately (or not so fortunately) I got disconnected from a game with the error I mentioned last time (c000011f). I was using WINEDEBUG=+winsock so I attach the output. Some of the information, however is in Bulgarian (my language) so I translate it to you: Крайната точка на транспорта не е свързана -> Destination point of the transport is not connected (or maybe relayed). (can be first seen on line 1106 Прекъснато системно извивкване -> Interrupted system call (can be first seen on line 984) Прекъснат канал -> Interrupted channel (can be first seen on line 1169) The c000011f error is on line 182283. However, unlike before, I was able to host a game without a problem, even though I received such problem. (but didn't wait for any people to join, so I can't tell if it worked properly or not, but at least it didn't crash battle.net this time ((or maybe it is related to recent bnet update which could've change behavior))
I archived the debug.log file, because it was 13 MB.
--- Comment #386 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-08-15 22:25:55 --- Created an attachment (id=23096) --> (http://bugs.winehq.org/attachment.cgi?id=23096) Set as of 8/15/2009
This is a new approach that should be a little more bug-proof. I'll keep working to get something committed. Thanks for testing.
--- Comment #387 from Florian florian@fkoeberle.de 2009-08-19 12:03:03 --- I tried to apply the patches to current git and to wine-1.1.17 but neither worked. Do you have a git repository to pull from?
--- Comment #388 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2009-08-27 18:14:39 --- (From update of attachment 23096) Florian, this set was outdated (and some of the patches made it into git). Use the latest set from wine-patches:
http://www.nabble.com/-PATCH-1-7--server%3A-add-alloc_sock-to-init-socket-ob... http://www.nabble.com/-PATCH-2-7--server%3A-change-accept_socket-to-take-a-s... http://www.nabble.com/-PATCH-3-7--server%3A-replace-reselect_async-by-async_... http://www.nabble.com/-PATCH-4-7--server%3A-add-accept_into_socket-and-regis... http://www.nabble.com/-PATCH-5-7--ntdll%3A-add-wine_server_clear_handle_fd-t... http://www.nabble.com/-PATCH-6-7--ws2_32%3A-implement-AcceptEx-td25180182.ht... http://www.nabble.com/-PATCH-7-7--ws2_32%3A-implement-GetAcceptExSockaddrs-t...
--- Comment #389 from Daniel sersmicro@gmail.com 2009-08-31 07:35:53 --- Mike, I really appreciate your work to get Battle.net working in Warcraft III, but I cannot figure out how to apply these patches correctly. I tried to apply these patches to wine 1.1.28 and to the latest git version, but neither of them worked properly. I had to resolve conflicts in "server/sock.c" and after that wine compiled fine. Unfortunately Battle.net still does not work. I hope that you will keep up your good work and find a solution if I did not make a mistake with those patches.
--- Comment #390 from Phil sefi@s-e-f-i.de 2009-09-07 08:34:06 --- Mike, I have applied your patches to the latest git head and hosting does work. I have hosted numerous games and had no problems at all. Some of the patches I had to edit by hand because they wouldn't apply no matter what although everything looked fine (maybe a white space problem?). Thanks for the good work.
--- Comment #391 from NSLW lukasz.wojnilowicz@gmail.com 2009-10-21 08:53:09 --- (In reply to comment #388)
Use the latest set from wine-patches:
There are some problems with applying second and fourth patch, but I corrected them so patches can apply. However there is error at the end of compilation of patched Wine-1.1.30 (the same for 1.1.31)
sock.c:921: warning: ‘struct accept_into_socket_reply’ declared inside parameter list sock.c:921: warning: its scope is only this definition or declaration, which is probably not what you want sock.c:921: warning: ‘struct accept_into_socket_request’ declared inside parameter list sock.c: In function ‘req_accept_into_socket’: sock.c:925: error: dereferencing pointer to incomplete type sock.c:929: error: dereferencing pointer to incomplete type sock.c:935: error: dereferencing pointer to incomplete type sock.c: At top level: sock.c:1061: warning: ‘struct register_accept_async_reply’ declared inside parameter list sock.c:1061: warning: ‘struct register_accept_async_request’ declared inside parameter list sock.c: In function ‘req_register_accept_async’: sock.c:1065: error: dereferencing pointer to incomplete type sock.c:1074: error: dereferencing pointer to incomplete type sock.c:1094: error: dereferencing pointer to incomplete type make[1]: *** [sock.o] Error 1 make: *** [server/__install__] Error 2