I correct myself. There is terminal output. This line is repeated 12 times:

fixme:ntdll:NtSetInformationFile Unsupported class (30)

I would also suggest you try these things, because it could be not wine, but if you want to save time:
* An older version of wine you know that last worked
* Check the battle.net status page
* Try different realms
* Check your network settings/connection
* Try blizzard forums/support and ask what the problem could be.

It does not make sense that this would regress where it would just "hang" but the regression test will identify if wine is truly at fault.

I compile git almost every day. That day's patches broke Bnet. I can confirm this by switching between an older wine (0.9.45) and git compiled that day.

Then please run the regression test so we can know the _exact_ patch that broke it.

http://wiki.winehq.org/RegressionTesting

*** Bug 9815 has been marked as a duplicate of this bug. ***

It does not work for me too (works fine with Wine 0.9.45)
but I do not get this line:

fixme:ntdll:NtSetInformationFile Unsupported class (30)

Wine is compiled with --disable-win16 --disable-debug --disable-trace 
maybe it's missing because of that. I tried all Window versions in winecfg
with the same results (2000 upwards because ME or older do not
work with the copy protection).

This is all I get:


localhost:~/.wine/drive_c/Programme/wc3$ wine war3.exe -opengl
fixme:cdrom:CDROM_DeviceIoControl Unsupported IOCTL 2d1400 (type=2d access=0 func=500 meth=0)
fixme:cursor:SetSystemCursor (0x1076,00007f8a),stub!

(several times the above)

err:ole:CoCreateInstance apartment not initialised
fixme:advapi:SetSecurityInfo stub
fixme:win:EnumDisplayDevicesW ((null),0,0x33eadc,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33ed50,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33ed80,0x00000000), stub!
fixme:imm:ImmAssociateContextEx (0x40024, (nil), 16): stub

Module: wine
Branch: master
Commit: 477582401b9a7b6baf188a788b9972c12495c51a
URL:    http://source.winehq.org/git/wine.git/?a=commit;h=477582401b9a7b6baf188a788b9972c12495c51a

Author: Andrey Turkin <andrey.turkin at gmail.com>
Date:   Tue Sep 18 00:00:45 2007 +0400

server: Implement server-side completion queues and operations on them.



This is the commit that caused this regression.

CC'ing author of patch.

Created attachment 8297 [details]
Allow async operations to generation completion events

It is not introduced bug but instead new partially implemented functionality. I hoped to send all patches in before new release, but one last patch did not make it. Seemingly Warcraft tries to use I/O completion port, and falls back to usual I/O in case of failure.
So, please try attached patch to see if it fix the game.

Patch applies correctly, however compiling fails.

directory.c: In function ‘NtNotifyChangeDirectoryFile’:
directory.c:2286: error: ‘async_data_t’ has no member named ‘cvalue’
make[2]: *** [directory.o] Error 1
make[2]: Leaving directory `/home/sebastian/wine-git/dlls/ntdll'
make[1]: *** [ntdll] Error 2
make[1]: Leaving directory `/home/sebastian/wine-git/dlls'
make: *** [dlls] Error 2

You need to run tools/make_requests script to regenerate some files. After that code should compile.

Is it commited to CVS or only in GIT

It is not committed anywhere yet; grab latest GIT (I think CVS tree is mirror of GIT), apply the patch, run tools/make_requests and build.
I hope to get this committed next week.

I get this when running make_requests: 

Cannot create include/wine/server_protocol.h at make_requests line 294.


Same compile error. 

You need to run "tools/make_requests" from wine tree root, not ./make_requests from tools directory. 

Ok that worked. Compiled with the patch, however B.net still doesn't work.


This line doesn't show up anymore like it did in .46 : 
fixme:ntdll:NtSetInformationFile Unsupported class (30)

EDIT:
This line does not show up in .46
fixme:ntdll:NtSetInformationFile Unsupported class (30)


So there's no visible difference between with and without the patch.

Regarding NtSetInformationFile: those fixmes should not be shown, they were shown when first patch of this batch was accepted but second was not yet. So this is normal.
Could you please get +sync,+winsock,+file debug log and attach it here?

Created attachment 8319 [details]
WINEDEBUG=+sync,+winsock,+file compressed bz2

Created attachment 8320 [details]
WinSock support for iocp

Please try again with this patch o top of first one (no make_requests needed for this one). If it won't help, then new +sync,+winsock,+file log would be needed.

With this patch B.net no longer idles with "Conencting to Battle.net", but with "Downloading Data Files". But if you re-try several times, it'll eventually successfully log in. 

Created attachment 8325 [details]
WINEDEBUG=+sync,+winsock,+file compressed bz2 #2

This is the log where B.net idles at "Downloading Data Files".

Created attachment 8341 [details]
WinSock support for iocp (fixed)

Sebastian, please this patch instead, as my previous patch was somehow broken (so use patch 8297 and this). Hopefully it will fix your issues. I'll send first patch to wine-patches, second needs some work before it can be sent, and I will wait for your confirmation just to make sure it is correct.

Second patch works great!

Thanks. :)

I've noticed one more problem. When you start a game, it takes a while for everyone to load the map. Normally when you're done the map the game sends a message to the other clients and when everyone's done the game starts. This doesn't happen anymore, you have to click (there's a "Click this when you're Ready" type of banner). You normally don't have to click for the message to get sent to other clients that you're done loading the map.

Hope a patch gets committed soon, because Andreys breaks the most recent code.

Created attachment 8368 [details]
Disable completion port creation

Created attachment 8369 [details]
Additional TRACEs

mortan, not sure I understood your comment. Do my patches break another application? Or do they break wine itself?

Sebastian,
I guess this would be harder to fix... First of all, please try if attach 8368 changes anything (this patch disables completion ports). If this fixes the issue, then please grab another log with "Additional TRACEs" patch (and without "disable completion" patch :)).

Created attachment 8370 [details]
compile output after patch

mortan, you have to apply 2 patches: 8297 (allow async operation to generate completion events) and 8341 (winsock support for iocp fixed) and then to run tools/make_requests. You either missed first patch, or didn't run tools/make_requests

I have some doubts that my last message arrived to you, so I resend it (sorry if I duplicate it):

[resend]

Thanks Andrey! I missed the first patch (8297), now it works.

[/resend]

Patch 8368 doesn't fix the issue. 

This problem really looks like something introduced by my patches, but you say disabling them does not work either.
Well, this patch disables main function programmers supposed to use, and thus keeps applications out of my patches. So, either
1) wc3 uses both kernel32 level and ntdll level functions (quite unlikely, can be checked by looking at WINEDEBUG=+sync logs for anything with Completion in it)
2) This Is Not My Fault (c) i.e. the bug caused by someone else's patch
I'd like to see traces with this patch applied just to make sure it is not me (it would be really shameful for me to have you run through regression test just to find that I am total dumb :)

Same problem here, wineversion 0.9.46, since 0.9.45 bnet works now doesn't work anymore, i downgraded to .45 and i have a new error message:
Can't connect to Bnet servers

Fabrizio, if the game don't work with wine-0.9.45, that a different problem (with a similar summary but this is not because of IO completion support).

(In reply to comment #35)
> Fabrizio, if the game don't work with wine-0.9.45, that a different problem
> (with a similar summary but this is not because of IO completion support).
> 

that's not true, couse since i had wine 0.9.45 installed with war3 all worked fine, after the last upgrade war3 stopped to work on bnet. I tryied to downgrade wine after the last update but i had that new message.
Do u need some log?

Fabrizio, your new problem is not related to this one. If your older version of wine is not working, you got a configuration problem.

(In reply to comment #37)
> Fabrizio, your new problem is not related to this one. If your older version of
> wine is not working, you got a configuration problem.
> 

Ok maybe couse i write not properly good english, but i want say that i had the same error that the other guy mentioned before.(I made a try downgrading but with no result)
The game hangs to "Connecting to Battle.net"
i'm back to wine 0.9.46 now

The point is that if you _properly_ downgraded to 0.9.45 there is no way my changes can break the game because they are not in 0.9.45! If you want you can try WINEDEBUG=+sync to check if iocp changes are still present in your installation.

With attachment 8297 [details] and attachment 8341 [details] I still have a problem with war3 on bnet when trying to host a game (no one can get into the game) or when someone leaves a game and possibly my client is supposed to take over the server role (I get disconnected). Perhaps there is some missing event for a incoming connection?

Jan, could you please attach +sync,+winsock trace for that issue? I thought only 4 functions can generate completion messages - WSASendTo, WSARecvFrom, AcceptEx and WSAIoctl (first 2 are hopefully covered, AcceptEx not implemented at all, and I doubt WSAIoctl causes the bug).

Created attachment 8528 [details]
log of opening a new bnet game with WINEDEBUG=+sync,+winsock

The log contains fixme:mswsock:AcceptEx... a few times. Then I tried with attachment 8368 [details] applied and it works again and there is no occurence of AcceptEx in the log.

About AcceptEx see also bug 280 .

I am also bitten by this bug on an ubuntu (gutsy) system for both the .46 and .47 .deb's. .45 is fine.

Andrey, do you intent to implement AcceptEx?

Yes, but that isn't so easy, and I had a busy week so I just started.

Created attachment 8676 [details]
log when i try to connect bnet WINEDEBUG=+sync,+winsock

Created attachment 8689 [details]
AcceptEx implementation

This is really hackish/lame implementation of AcceptEx function; please try it instead of attachment 8341 [details]

Created attachment 8690 [details]
errors during compilation

Hello Andrey!

Your Patch breaks the code for me. I checked out the latest version from git, patched it and run tools/make_requests. This leads me to the errors in my attachment.

Regards,
Fabian

Whoops. I think I should always specify all patches to be applied. Here I meant use attachment 8297 [details] and attachment 8689 [details] together

Andrey,

after your other patch wine compiles fine. I can indeed connect to the battlenet, but joining / hosting a game results in a crash. I try to send you a dump of the output tomorrow because it's quite late now... Let me know if you need any special information!

I just wanted to confirm the bug:

Debian Etch 4.0, Enlightenment E17, Warcraft III TFT v1.21:

with wine 9.45 everything works fine
with wine 9.46/9.47 I am unable to connect to the Battlenet

Created attachment 8715 [details]
output from WINEDEBUG=+sync,+winsock

Andrey,

I've attached the log file (game hangs while joining a game).

Forgive me for being new to this but I thought I might mention something I noticed. 

I was able to connect to bnet with 9.45 and now with 9.46 I can't. I tried connecting while looking at my packets with wireshark and I've noticed that some(if not all) packets from warcraft are being marked as having a bad checksum. I haven't confirmed that this wasn't happening before(I'm not sure of the best way to revert to 9.45), but I assume that the packets must have been fine before.

Not sure if that helps any but you can try it yourself and see. 

   

troy, that has nothing to do with this issue; broken checksums you see are likely caused by checksum offloading (which means NIC itself generate correct checksum, while Wireshark captures not yet prepared packets). Anyway Wine hardly can change something that low-level as IP fields, esp. unintentionally.

Has anyone tried 0.9.48? Does the bug still exist?

(In reply to comment #56)
> Has anyone tried 0.9.48? Does the bug still exist?
> 
Yes, it does.

This regression occurred after 0.9.43.  If I revert back to 0.9.43 everything starts working again; if I upgrade to 0.9.44 or higher, Battle.net stops working in wine.

Micael, you are facing some other bug then. This bug is about code merged just before 0.9.46 release, and it can't cause regression in 0.9.44. Please do regression test to find commit that broke the game for you and file new bug for it.

My bad, I test 0.9.45 and it works.  However, when I upgrade to 0.9.46 it breaks as this thread describes.  So it looks like I'm in the same boat.

This is not only b.net related, it additionally affects LAN play. This bug was introduced (at least for me) with 9.46. 9.45 works fine.

Same problem, was introduced with wine version 9.46. terminal output is attached in http://bugs.winehq.org/show_bug.cgi?id=10084 .

Andrey Turkin what kind of information do you need to fix this bug?

If you need some kind of log please tell me which patches have to be applied to which version of wine. Or do you have a public branch with that patch to pull from?

(In reply to comment #25)
> I've noticed one more problem. When you start a game, it takes a while for
> everyone to load the map. Normally when you're done the map the game sends a
> message to the other clients and when everyone's done the game starts. This
> doesn't happen anymore, you have to click (there's a "Click this when you're
> Ready" type of banner). You normally don't have to click for the message to get
> sent to other clients that you're done loading the map.
> 

I have very often received the "Please click when ready" message, both in wine and not. I believe it is up to the creator of the map to decide if it is there or not.

As I was myself a extended war3 modder, I can tell you that this is determined if you replace the standard wc3 map loading screen pics or use a campaign or custom pic. This is not related to this bug.

I am currently using a self compiled version of 9.45 source for gutsy.

Florian,

at the moment I do not need information, I can use some experience in Wine's winsock implementation though :)
I hope latest version I sent to wine-patches will be committed, then only thing left would be AcceptEx implementation, and that's the problem 'cause I don't know much about that area. I'll post a patch for that when done.

*** Bug 10304 has been marked as a duplicate of this bug. ***

updating summary -- reports show the whole game is broken.

Only the network part does not work - since .46. Singleplayer is fine for me.

Singleplayer is fine, only Multiplayer is broken.

I can confirm that the loading of singleplayer games is broken in Wine 0.9.47. I tried to start the first mission of the campaign and loading a saved game. Both stopped at about ~70%.

I can reproduce the bug with Wine 0.9.47 and the Warcraft 3 Demo, which can be downloaded here:

http://www.blizzard.com/war3/demo/

Notice that the Singleplayer freeze doesn't happen always, but sometimes when loading, starting or saving games.

Well the regression for both single and multiplayer can be traced to the same patch. Whether there are multiple problems that need to be address (and some have so far), is probably true as there is already more than one patch. I'll let Andrey decide how to handle all of them.

*** Bug 10334 has been marked as a duplicate of this bug. ***

The patches in attachment 8297 [details] and attachment 8689 [details] fixed the hanging problem I had when loading a level in a single player game, but I've tried on two occasions to play the game and both times around 10-15 minutes into it the entire X session froze (ie I couldn't move the mouse, alt-tab, or even reset the X session with ctrl-alt-backspace).

The second time I ssh'd into the PC from another PC and found that X-org was taking up close to 100% CPU time (wine and war3.exe were taking up less than 1%). I tried killing war3.exe, then wine-server, with no effect. Then I killed -9 X-org, which hung the entire PC including the remote ssh session.

November 9, 2007: Wine 0.9.49 Released
So I updated my wine repositories to version 9.49 and started FrozenThrone.exe
Immediately I tried to connect the battlenet, but the result is the same as everytime (version>9.45).

With due respect, why can this not be put back to the way it was before the patch?

Three versions of wine now and still what was working before is broken...

It's surprising how much eMails with redundant content I got through bugmail over the last weeks.

Summary
----------------------

Wine version 0.46 broke most of WarCraft 3 multiplayer functionality (Battlenet and LAN) and even parts of the singleplayer.
This is likely related to Andrey Turkins patches which partially implements a new functionality (http://bugs.winehq.org/show_bug.cgi?id=9787#c9).

What left is the correct implementation of the AcceptEx function (http://bugs.winehq.org/show_bug.cgi?id=9787#c66), which WarCraft probably needs for single- and multiplayer.
There is a patch with an ad hoc implemention of AcceptEx (http://bugs.winehq.org/show_bug.cgi?id=9787#c48), but it don't work yet.

So as an user, you have to wait until AcceptEx is fully implemented or revert back to version 0.45 or earlier.

----------------------

I hope that I don't missed any facts.

Hmm, AcceptEx almost sounds like something we should fix for 1.0...

I vote for 1.0 too. It would be silly to let this go on when the game has worked for so long.

This shouldn't be aimed for 1.0, just for the nixt release...
It's really annoying. The 9.45 I compiled myself randomly freezes my PC while playing wc3 -.- aswell does the debain etch version of wine 9.45

plx, fix it, or give us a patch to revert to the old winenet stuff to get over the waiting time.. thx anyways, wine easily owns cedega...

I have also voted.

Andrey, any news on ther AcceptEx implentation? Would be really, really appreciated.. Sorry for bugging you.

Is there a free trial?

Yes, there's a demo: http://www.blizzard.com/war3/demo/

First of all: those of you who just want to workaround this bug can use attachment 8368 [details], which disable iocp functionality.
I cannot fix this bug now, or in next release - it is not me who decides. All patches must be accepted by Alexandre, and he especially picky about server patches. Those who read wine-patches have seen that I've sent 4th version last week.
Regarding AcceptEx - I'm trying, but it still doesn't work as it should.

Thanks for your work. :)

Yes, thank you very much for your hard work.  It is surely appreciated.

As for your patch disabling iocp, I modified the wine ebuild in my portage overlay and remerged wine.  The patch is confirmed to work for Warcraft 3 (at least), so good on you ;)

Excuse my ignorance, but if AcceptEx is keeping TFT from running BNet, then shouldn't Bug 280 be labled as a blocker? Can this also be affecting other Blizzard games that use BNet? (Starcraft, Diablo?)

(In reply to comment #88)
> Excuse my ignorance, but if AcceptEx is keeping TFT from running BNet, then
> shouldn't Bug 280 be labled as a blocker?

No, according to the explanation of the severity levels, a blocker "Blocks development and/or testing work" i.e. stops Wine from building from source.

This bug only affects one application, as far as I can see.

> Can this also be affecting other
> Blizzard games that use BNet? (Starcraft, Diablo?)

Not to my knowledge. However, have not tried those.

*** Bug 10514 has been marked as a duplicate of this bug. ***

*** Bug 10514 has been marked as a duplicate of this bug. ***

This bug is fixed in 0.9.50. :)

I have just compiled it and it worked well on the first try.

I also tried the new version. Connecting to Battlenet and joining games works but hosting a game doesn't because this part of AcceptEx (as noted in the stub messages) is still unimplemented.

wine 0.9.50 fixes my problems with Warcraft III, ie it no longer waits forever while loading a level, and it doesn't freeze the entire PC randomly (at least I managed to play an entire level without a freeze). Brilliant!

i don't know if Andrey Turkin's added feature is any good, but i think that networking in games is a very important function of wine, and the added feature should be branched unstable.
for example think of all the windows => ubuntu gutsy switchers who can't help themselves and classify gaming impossible with wine, which was fine until version 9.45.
world of warcraft networking works fine btw with 9.46, tested on my friends fresh installed ubuntu gutsy gibbon, while wc3 does not.

i will swich back to the last "stable" version (for my purposes) of wine, 9.45 until this issue is fixed.

i thank you for your hard work guys, you make my unix system more enjoyable.

Created attachment 9450 [details]
log produced by wine-0.9.50 when hosting a Battle.net game in Warcraft 3 The Frozen Throne

With wine-0.9.50 it is possible to join Battle.net games. If you host a game then no one joins, but a lot of fixme:mswsock:AcceptEx messages appear.

Please fix this last part of the bug. If you need logs or something similar please tell me.

With 0.9.50 Warcraft 3 Frozen Throne crashes one second into a Battle.net game... A problem still exists.

(In reply to comment #95)
> i don't know if Andrey Turkin's added feature is any good, but i think that
> networking in games is a very important function of wine, and the added feature
> should be branched unstable.

This comment makes me wonder what gave you the impression that a beta release was stable? It's not called 0.9.x for nothing.

> for example think of all the windows => ubuntu gutsy switchers who can't help
> themselves and classify gaming impossible with wine, which was fine until
> version 9.45.

We're considering that. And then we're considering the fact that there's not really that many people working on Wine, and that having those divide their attention between a stable branch and an unstable branch might not make sense quite yet. We're working towards a version we're happy to branch off as "stable", but we're not quite there yet.

Will you people please stop whining?  The Wine developers are doing great work.  They are doing it for free and you're complaining that it isn't good enough.  Well, if it isn't, why don't you fix it yourself and submit a patch to the wine mailing list?  Oh, wait, you don't know how?

Let's all remember that Wine is a F/OSS project.  Lets also remember that there is a patch that disables iocp [attachment 8368 [details]] -- this can be applied to the latest release to force a reversion to the old behaviour.

Thank you very much to all those who are committing their valuable time and hard work to this project.

The fix works great, but you know how sometimes you join a game and all the buttons become disabled but nothing happens , and you receive and error only about a minute later? 

It seems that now my buttons get disabled, and I never receive any error, so basically I'm stuck and have to restart TFT. Happens every time.

Does this happen to anyone else? Is it linked to the patch?

(In reply to comment #100)
> The fix works great, but you know how sometimes you join a game and all the
> buttons become disabled but nothing happens , and you receive and error only
> about a minute later? 
> 
> It seems that now my buttons get disabled, and I never receive any error, so
> basically I'm stuck and have to restart TFT. Happens every time.
> 
> Does this happen to anyone else? Is it linked to the patch?
> 

no, this is another bug, i had this before.
do you mean before you join the game, in the game list screen?

(In reply to comment #101)
> (In reply to comment #100)
> > The fix works great, but you know how sometimes you join a game and all the
> > buttons become disabled but nothing happens , and you receive and error only
> > about a minute later? 
> > 
> > It seems that now my buttons get disabled, and I never receive any error, so
> > basically I'm stuck and have to restart TFT. Happens every time.
> > 
> > Does this happen to anyone else? Is it linked to the patch?
> > 
> 
> no, this is another bug, i had this before.
> do you mean before you join the game, in the game list screen?
> 

No thats not really a Bug. Just the timeout is higher for non responding Games. If you wait a few minutes you will be fine. Thats the same in 9.45 btw.


But there is another thing: I dont see all textmessages ingame and in the gamecreation chat. There are allways some player whos msgs i cannot read(they dont appear to me). Thats introduced after 9.45 but i cant run the regression test right now.

I'm not convinced that the button disable problem is unrelated.

Before (say 0.9.45ish) occasionally connecting to a game would fail... waiting 2-3 minutes would eventually return a failure message. This is similar to what happens under windows and might occur say 10% of the time.

Since the AcceptEx stuffing about of the last few weeks, when a game fails to connect most often you NEVER receive a failure message (say 99% of the time, very very infrequently it returns a failure message) and the only solution is to kill the war3.exe process and restart.

This issue was there for a long time and has been fixed some time ago, see bug 4619. maybe the patch there just has to be reapplied.

Created attachment 9754 [details]
Crash error log

Crash error log

After enable completion port creation, Warcraft3 random crash when saving game, see attached log.

If I disable completion port creation, it's OK.

(In reply to comment #106)
> After enable completion port creation, Warcraft3 random crash when saving game,
> see attached log.
> 
> If I disable completion port creation, it's OK.
> 

I can confirm that.

Additional to that text messages from some other players wont be displayed or logged ingame and in gamecreation chat. Host text messages are always readable.


PS: If you search for open bugs with over 30 votes you will find 2 bugs. One of them is this one. I  cant fix it myself, but i still complain since it is a regression bug and i don't want to miss some new compatibility fixes in the latest wine.

With this patch

http://bugs.winehq.org/attachment.cgi?id=8368

applied to the wine sources (works up to .52) it works the old way.

Created attachment 10028 [details]
partial AcceptEx implementation

Hi guys,
sorry for long silence.

Here attached is partial AcceptEx implementation; with it I was able to host the game. Please do not forget to run tools/make_requests after patching.

Oh, and if you'll see any crash, please attach at least backtrace log! I cannot fix anything without info.

Will this patch be included in 9.53?

Btw. I'm a noob, but plx: do I have to patch the source and compile or can I patch the installed wine? Which comand does the job? patch or diff ??
Sry for that interrupt..

(In reply to comment #110)
> Will this patch be included in 9.53?
> 
Very unlikely. I'm not going to send this patch as is, instead it has to be splitted into several patches, some of them are somehow objectionable (I'll have to confirm they do right thing), some of the patch should be tested/improved, and some part should be done differently.
> Btw. I'm a noob, but plx: do I have to patch the source and compile or can I
> patch the installed wine? Which comand does the job? patch or diff ??
> Sry for that interrupt..
> 
Yes, as all other Wine patches, this one should be applied to the source (cd wine-source-dir && patch -Np1 < /patch/filename && tools/make_requests)

Thx a lot, for help and patch. I'm going to test it.

Patch 8368 from #108 works fine, so why to try to make new ones?

(In reply to comment #113)
> Patch 8368 from #108 works fine, so why to try to make new ones?
> 

Because that is workaround which will disable IOCP support. Many apps require IOCP support, and some of them also require AcceptEx support, so Wine _have_ to implement both IO completion ports and AcceptEx; this is what I try to do!

(In reply to comment #114)
> (In reply to comment #113)
> > Patch 8368 from #108 works fine, so why to try to make new ones?
> > 
> 
> Because that is workaround which will disable IOCP support. Many apps require
> IOCP support, and some of them also require AcceptEx support, so Wine _have_ to
> implement both IO completion ports and AcceptEx; this is what I try to do!
> 

Would you mind sending the patches to the dev list? I think that would make verification much faster. YES i can't await working AcceptEx in wine! :) 

Good work Andrey!

Patch (id=10028) from post #109 workes fine for me. SOmeone to verify? I am runing ubuntu 7.10 x86_64

i agree to Martin Bosner  . At least for a temporal fix this would be great! Great job Andrey Turkin!

After i  patched the gentoo 0.9.52 version:

I allways get this compile error:

socket.c: In function 'AcceptEx_recv':
socket.c:1364: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'SOCKET'
socket.c: In function 'WS2_async_accept':
socket.c:1391: error: 'struct accept_socket_request' has no member named 'ahandle'
make[2]: *** [socket.o] Error 1
make[2]: Leaving directory `/var/tmp/portage/app-emulation/wine-0.9.52/work/wine-0.9.52/dlls/ws2_32'
make[1]: *** [ws2_32] Error 2
make[1]: *** Waiting for unfinished jobs....


What did i do wrong?

Created attachment 10052 [details]
Patched gentoo 0.9.52 (Patch acceptex.patch) build error log.

(In reply to comment #118)
> After i  patched the gentoo 0.9.52 version:
> 
> I allways get this compile error:
> 
> socket.c: In function 'AcceptEx_recv':
> socket.c:1364: warning: format '%x' expects type 'unsigned int', but argument 5
> has type 'SOCKET'
> socket.c: In function 'WS2_async_accept':
> socket.c:1391: error: 'struct accept_socket_request' has no member named
> 'ahandle'
> make[2]: *** [socket.o] Error 1
> make[2]: Leaving directory
> `/var/tmp/portage/app-emulation/wine-0.9.52/work/wine-0.9.52/dlls/ws2_32'
> make[1]: *** [ws2_32] Error 2
> make[1]: *** Waiting for unfinished jobs....
> 
> 
> What did i do wrong?
> 

I'd bet you forgot to run tools/make_requests after patching

Ok after i got it to work (the new patch) i ran into new problems:

I randomly get disconnected from BNET and when i rejoin i get the following exception.

Created attachment 10054 [details]
crashlog from the latest patch

LAN play definitly works
And I just tested b.net and this seemed to work aswell.. well

(In reply to comment #123)
> LAN play definitly works
> And I just tested b.net and this seemed to work aswell.. well
> 

LAN play does not work. If there is some lag because of loading etc. you get a disconnect to the host and if you rejoin a game WC3 crashes.

Normal BNET was like the same for me.

Playing BNET with LC (ListChecker simulating a lan host for 100ms game latency) i could start a game but disconnected after some seconds. This is may come from little packet loss. But i cant confirm that.

Hmm... I played WC3 a bit with current git an this patch, though I didn't host the game. We played a bit of DotA(ouch), the AI version actually. When the AI picks their heroes there is a short freeze, sometimes with the player timeout warning window. I survived all of those situations just fine, but I don't know if I ever timed out, since the window is shown for a very short time, if at all.

(In reply to comment #125)
> Hmm... I played WC3 a bit with current git an this patch, though I didn't host
> the game. We played a bit of DotA(ouch), the AI version actually. When the AI
> picks their heroes there is a short freeze, sometimes with the player timeout
> warning window. I survived all of those situations just fine, but I don't know
> if I ever timed out, since the window is shown for a very short time, if at
> all.
> 
Well, i am a DotA player in a DotA Clan and playing about 3-10 Games/Day... using wine on gentoo 2.6.23-rc3.

Of cource most games i play is with LC (faking LAN Game in BNET) with much less latency, just search for ListChecker.

I cannot host and i did not even try with the patch, because i could not play one game till the end.

I attached my crash.log with my first result post (5.1.2008-GER). Maybe you can tell whats happening. If you need more i am free for testing. I did NOT patch the latest GiT but 0.9.52.

So if you have any further questions mail me directly or post here.

Martin

PS: I just want to make it better and working - no bashing or something.

I tried new patch and it is not so good. I've tried to join a game about 10 games and everytime it kicked me without any output in log. Maybe I hadn't today a lucky day, but I reinstalled it back and everything worked again without any kick. 

However, I was able to host a game, so hosting is probably solved.

Created attachment 10107 [details]
basic AcceptEx implementation try 2

So first patch added a regression.
Please try if this patch works better (both hosting and joining the game)

(In reply to comment #128)
> Created an attachment (id=10107) [details]
> basic AcceptEx implementation try 2
> 
> So first patch added a regression.
> Please try if this patch works better (both hosting and joining the game)
> 
It's getting better. Still, wc3 crashes when exiting:

err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x7dd2fb9a

I am pretty tired and will sum up all remaining bugs later (tomorrow).

Good work

lol.. strangely it works fine for me again
just played about an hour DotA via b.net
LAN works fine aswell for me

Sry, last info was wrong.
It seems to be that I am now not able to host a game, but this may be caused by using an router...
So Iam not quiet sure if its a lack of the patch or the dumbness of b.net & my router.
At least nobdy joined my DotA game, which is quite famous and someone would have choosen if possible. :-/

(In reply to comment #128)
> Created an attachment (id=10107) [details]
> basic AcceptEx implementation try 2
> 
> So first patch added a regression.
> Please try if this patch works better (both hosting and joining the game)
> 

Okay so i was able to play one game without kick. I am pretty bussy at work this week so u could not play another game.

So far so good. 

But i got kicked out of the gamecreation chatlobby randomly.

And i get kicked out of bnet when i try to join timed out games. I will append a screenshot.

(In reply to comment #128)
> Created an attachment (id=10107) [details]
> basic AcceptEx implementation try 2
> 
> So first patch added a regression.
> Please try if this patch works better (both hosting and joining the game)
> 


I got following output while patching git version from Wed Jan 9 13:02:01 2008 +0100 :

patching file dlls/mswsock/mswsock.spec
patching file dlls/ws2_32/socket.c
Hunk #2 succeeded at 1355 with fuzz 2.
patching file dlls/ws2_32/ws2_32.spec
patching file server/protocol.def
patching file server/sock.c
Hunk #1 FAILED at 514.
Hunk #2 FAILED at 621.
2 out of 4 hunks FAILED -- saving rejects to file server/sock.c.rej
joe@laeppi ~/build/wine $ cat server/sock.c.rej
*************** static void sock_queue_async( struct fd *fd, const async_data_t *data, int type,
*** 514,520 ****
          return;
      }
  
-     if ( ( 
           ( !( sock->state & FD_WRITE ) && type == ASYNC_TYPE_WRITE ) )
      {
          set_error( STATUS_PIPE_DISCONNECTED );
--- 514,520 ----
          return;
      }
  
+     if ( ( !( sock->state & (F
           ( !( sock->state & FD_WRITE ) && type == ASYNC_TYPE_WRITE ) )
      {
          set_error( STATUS_PIPE_DISCONNECTED );
*************** static struct object *create_socket( int family, int type, int
*** 621,629 ****
  }
  
  /* accept a socket
- static struct sock *accep
  {
-     struct sock *acceptsock;
      struct sock *sock;
      intacceptfd;
      struct sockaddrsaddr;
--- 621,629 ----
  }
  
  /* accept a socket
+ static struct sock *accept_socket( obj_handle_t handle, obj_handle_t ahandle )
  {
+     struct sock *acceptsock = NULL;
      struct sock *sock;
      intacceptfd;
      struct sockaddrsaddr;

*** Bug 11202 has been marked as a duplicate of this bug. ***

I applied the patch to 0.9.53 source and compiled successfully. Playing wc3 over LAN has some limitation in the respect of stability. After ~1h of playing one and the same the game freezes and I have to kill the wine server. No error turns op like conecten error or whaterver. 

I tried the patch in attachment 10107 [details] and it seems to work for warcraft3 (hosting a b.net game and playing) although I didn't play long.

Just wanted to say I compiled wine with the patch successfully and was able to host both warcraft 3 Rain of Chaos and The Frozen Throne games.  I played for several hours without any noticeable problems.  Great work!

I compiled WINE 0.9.54 with the new patch and had no problems with that.  

I tried to host a LAN game with another computer running WINE 0.9.42 (the last really stable release for The Frozen Throne).  The other computer was able to see the hosted game, but not connect.  

Would this new implementation of AcceptEx be incompatible with the old?

Thanks,
D

I tried to compile wine 0.9.54 using the latest patch, but gcc fails with the following errors in the directory dlls/ws2_32:
socket.c: In functie ‘AcceptEx_recv’:
socket.c:1378: let op: format ‘%x’ expects type ‘unsigned int’, but argument 5 has type ‘SOCKET’
socket.c: In functie ‘WS2_async_accept’:
socket.c:1405: fout: ‘struct accept_socket_request’ has no member named ‘ahandle’
socket.c: In functie ‘AcceptEx’:
socket.c:1455: fout: ‘struct accept_socket_request’ has no member named ‘ahandle’

You need to run tools/make_requests (see earlier comments)

I've stuck some Fedora 8 RPMs of wine 0.9.53 with the patch applied on my web page to save anyone else in the same boat as I some time: http://www.xades.com/projects.html#winewc3

Martin

I compiled this with WINE 0.9.56 with no problems.  Works great on a PVPGN server and LAN games.  Nice Job.

D

Yep, Andrey did a good job. The last AcceptEx patch works for me quite well. There is only one drawback I experienced: Sometimes (very rarly) when you join a game all controls in the UI gets disabled (this is normal) but WarCraft 3 remains at this state. If I recall correctly, this sometimes occur in Windows too, but WC3 then displays a dialog with something like "Could not connect to game" after 20 seconds or so.

Yes, this even happens with the current version of wine and previous versions as well. So this may not be related to this patch.

The issue with the controls remaining disabled had been fixed so that it did not appear in 0.9.43 and previous but it reappears when using the AcceptEx implantation.

See bug 4619.

It's in windows as well, it happened to me several times.

Do the buttons reapper in Windows after some time? This is what I have experienced some time ago in contrast to early Wine releases.

I have usually lost patience after several minutes, and restarted Warcraft. Therefore, I don't think it's wine only bug...

The "controls get disabled" problem has occured for me too, but it only happens when the hosting computer of a multiplayer game doesn't have the proper ports open.  

When this happens I usually just kick them from the server and I get the controls again; otherwise, it takes many, many minutes to get them back, if at all.  (Usually never.)

I then procede to gently remind my friends of their network situation.  :]

D

(In reply to comment #143)
> There is only one drawback I experienced: Sometimes (very rarly) when you join
> a game all controls in the UI gets disabled (this is normal) but WarCraft 3
> remains at this state. If I recall correctly, this sometimes occur in Windows
> too, but WC3 then displays a dialog with something like "Could not connect to
> game" after 20 seconds or so.
> 

This is actually a bug with joining games that Blizzard apparently fixed for the Windows version if I recall reading a changelog correctly and it appears to be network related and only happens within the game browse screen. 

There had been Wine versions that did not trigger this state for me around the ~0.9.4x series aswell.

If you run WarCraft 3 under Windows the locked controls gets enabled after some time, if I recall correctly. But it has not to be an flaw in the AcceptEx implementation as I'm not 100% sure about that.

(In reply to comment #151)
> If you run WarCraft 3 under Windows the locked controls gets enabled after some
> time, if I recall correctly. But it has not to be an flaw in the AcceptEx
> implementation as I'm not 100% sure about that.
> 

in fact it happens when u join a game and the host have the ports blocked from a firewall or nat, in other words when his ports are unreachable
In windows you have a timeout limit, in linux you haven't

I have successfully compiled this in with WINE 0.9.57.  I have openSUSE 10.3 RPMs for both x86 and x86_64 at this location:

http://download.opensuse.org/repositories/home:/dbuck/openSUSE_10.3/

Note that this versino of WINE is a project of mine to get all functionality working with x86_64 as well, so there may be a few extra dependencies that you need to install.  (Right now everything is working in x86_64 except libgphoto2.)


On another note, I notice that when hosting a game, playing, then finishing, I have to restart The Frozen Throne again in order to host again.  As if the patch stops working....   But I don't mind it that much.

Thanks
D

I sadly do not have the programming skills that are needed to solve this problem, but I would love to see it fixed (mainly because it is a WINE 1.0 blocker and also partly because it exists in the bugzilla for such a long time). Would be great if there would be some progress :)

I think the right way to go from here is that someone collects all the informations that covers what is left to do.

What does not work until yet?
What is wrong / incomplete with the current implementation?
What is left to be done?

If all the informations are covered the wine developers can mark this bug as crictial and release blocking and finally get it done.

I'm now trying the patch with Wine 0.9.58 and will report my results shortly.

The thing that I am wondering is: Why not apply the patch to Git and wait for the incoming bug reports? This way the patch reaches a wider audience. Also, it does not break existing things AFAIK.

To whom it may concern; Wine 0.9.58 Fedora 8 RPMs can be found here: http://koji.fedoraproject.org/koji/taskinfo?taskID=526538


The patch seems to work for me but I have to try it a little bit more.

Test results: 

+ Hosting works
+ Playing works

- Game freezes when closing it via the "Quit" button
- I did not try to reproduce the issue mentioned here: http://bugs.winehq.org/show_bug.cgi?id=9787#c145

I just want to confirm that the latest patch does NOT BEHAVE like the old 0.9.45 wine version. Still sudden disconnects and chatproblems: i can not see all written messages in gamecreation chat or ingame chat. That is not per message but per player. I can allways see messages from the host.

Sorry this is not fixed.

In addition to that there are some other not so important problems.

(In reply to comment #159)
> I just want to confirm that the latest patch does NOT BEHAVE like the old
> 0.9.45 wine version. Still sudden disconnects and chatproblems: i can not see
> all written messages in gamecreation chat or ingame chat. That is not per
> message but per player. I can allways see messages from the host.
> 
> Sorry this is not fixed.
> 
> In addition to that there are some other not so important problems.
> 

No, No! If you found other "minor" problems, then please report. That's quite important on the way to fully implement the network feature.

(In reply to comment #159)
> I just want to confirm that the latest patch does NOT BEHAVE like the old
> 0.9.45 wine version. Still sudden disconnects and chatproblems: i can not see
> all written messages in gamecreation chat or ingame chat. That is not per
> message but per player. I can allways see messages from the host.
> 
> Sorry this is not fixed.
> 
> In addition to that there are some other not so important problems.
> 

That was my experience exactly. Can only see chat from host, and occasionally another player, and sudden disconnects and long lag spikes. When using 0.9.45 wine version everything is near perfect.

I know that I have already posted that before, but for me, in *normal* games on Battle.Net (like 1v1 2v2 3v3 4v4) - which means no own maps, there aren't any regressions. That's why I'd say apply it and try to get some order on which regressions appear - collect logs and fix them after.

The Wine 0.9.xx releases never used to be seen as "stable" versions, so why not add a patch which adds some new features and is not some dirty hack. Then we can modify it so that it works like a charm with Wine 1.0. Is there anything in the policies that prevents working like this?

Maybe it's a good idea to spread the patch to the masses...

I'll set up a git repo again so I can test the patch a bit more indept. Hopefully I'll find some time this weekend for this.

(In reply to comment #162)
> The Wine 0.9.xx releases never used to be seen as "stable" versions, so why not
> add a patch which adds some new features and is not some dirty hack. Then we
> can modify it so that it works like a charm with Wine 1.0. Is there anything in
> the policies that prevents working like this?
> 

To quote Stefan from [1]:

"Wine has a no-hacks policy, mainly because as soon as we start committing this
one hack hundreds others will come and Wine is unmaintainable within weeks.
Since Wine is open source you're free to branch and give it a try."

[1] http://bugs.winehq.org/show_bug.cgi?id=1347#c22

Yes, but the patch is no hack, is it?

I have been testing this patch for a long time now, and it seems ok.  

Only once did I get an issue where messaging others in game didn't seem to
work.  Many times, almost consistently in fact, do I get the issue above where
if I host a game, I need to restart Frozen Throne in order to host again.

Recently I have been compiling wine-hacks found at:
http://repo.or.cz/w/wine/hacks.git

which includes this AcceptEx patch.  I create openSUSE RPMs for this too at:
http://download.opensuse.org/repositories/home:/dbuck/

I have added a few more SUSE distributions to the list.  The packages named
"wine" have only the AcceptEx patch compiled in, whereas the packages named
"wine-hacks" are builds of the wine-hacks.git.

I think I would like to see more testing before this makes it into mainstream
WINE.

D

Well, the freezing issue has been mentioned a lot here and I have also experienced it. There are also many logs available regarding this issue. 

Andrey, would be definitly nice if you could have a look at it. 

Just some information about the freezing problem that I have collected:

It has been fixed in commit 24b64534e592e47e5cac70e497a98c0ddbc3941b , see http://www.winehq.org/pipermail/wine-cvs/2006-December/028326.html Also see bug 4619. This would have to be added to the AcceptEx implentation probably.

Well, the patch is still applied and the code is in sock.c, so I dunno what's causing the issue now. May be worth looking at the bug, though.

I think the freezing issue appears most of the time as a result of people not properly setting up their network...  I have never had it freeze when my network was set up properly, and I have played a lot on different machines.

Yeah we've all had that when port 6112 of the host is blocked by a firewall or nat.. same symptoms as in bug 4619, but something is different here..

I just want to state that for me personally the first "hack" appeared in 0.9.46.

If you apply the latest patch from Andrey Turkin i would rate WC3 as garbage because i ONLY play a custom map (DOTA). There are over 200k DotA Player in Europe.

dota-allstars.com <- the custom map

dota-league.com <- the league

Sorry but thats the truth.

I too am still regularly experience the chat problem. I often only see messages from the host, and maybe 1 or 2 other players. (This is usually DOTA custom games)

I very occasionally get unexplainable disconnections. My network connection is reliable but I can't discount something actually breaking in the network connection rather than in wine.

I still very regularly get hangs when connection to a custom game. This seems related to either network congestion on the host end or port forwarding problems on the host end. The game just sits hung and never recovers and the darkened screen before you would enter the game setup screen. This happens far far more frequently than under windows, however it does happen in windows from time to time. Having said that windows very often recovers from this whereas wine/linux rarely does.

> If you apply the latest patch from Andrey Turkin i would rate WC3 as garbage because i ONLY play a custom map (DOTA).

Well, you'd have to rate the current wine git as garbage anyway :)

Would be probably worth producing logs with WINEDEBUG=+sync,+winsock,+file for every single issue that you run into and attach it here with a describtion which problem appears. Sadly Andrey seems to be not here otherwise he could tell us which information he needs.

I have played the DotA map plenty of times on a PVPGN server and have had no problems.  Although it could be that the traditional battle.net servers make use of different commands.

When i do get the hanging problem because the host of a custom game didn't configure their network properly, one of my machines recovers consistently whereas another doesn't recover just as consistently.

I am willing to debug a little if I was told specifically what to do.

D

I just did some funmap playing on the official Blizzard Battle.Net server for Europe and it worked just fine, except the already mentioned freeze when host is behind nat issue.

I'm not sure what the difference between my and Martin Bosner's setup is, maybe you can give some details Martin? I am using Fedora 8 with NVIDIA drivers and Wine 0.9.58 using the AcceptEx patch.

(In reply to comment #175)
> I just did some funmap playing on the official Blizzard Battle.Net server for
> Europe and it worked just fine, except the already mentioned freeze when host
> is behind nat issue.
> 
> I'm not sure what the difference between my and Martin Bosner's setup is, maybe
> you can give some details Martin? I am using Fedora 8 with NVIDIA drivers and
> Wine 0.9.58 using the AcceptEx patch.
> 

Thats pretty easy: I tested it on Gentoo and Ubuntu - always latest Version patched with the latest patch.

Using Nvidia and Ati video hardware on onboard and Intel PCI LAN Hardware.

Allways AMD X² and both 32/64 bit.

The main difference may be the use of tools to reduce the latency (fake LAN mode for WC3).

But those tools are only used by the host and not by me. And yes these tools are a MUST HAVE in league games etc. Else the delay is too much for dota (its NOT a RTS Map of WC3 but more like WOW ;)

Sorry about my last comment but i was a little bit pissed about the "here everything is fine... are you sure that it is not you" stuff.

Its a wine implementation bug of accept_ex and not my mistake.

Yes it does not occur in normal BNET HOSTED (bnet is distributing game data at normal slow mode).

The "Grey screen bug" does also occur on windows but not nearly as many times (feeled) as in windows. That may happen because of packets the host is sending to the client that tells him "game is full" or something. I tried pretty hard but never got a "game is full" message with the patch. Maybe there is a starting point for bug hunting.

Well, now we know that it only happens when the host uses a special tool..

(In reply to comment #178)
> Well, now we know that it only happens when the host uses a special tool..
> 

If you would have read my post #124 From Martin Bosner  2008-01-05 10:32:12 you would know that already.

But it is the same for lan because the tools are only announcing lan games in bnet and allow others to join your lan game.

Ok, late one but...

I tested the last patch from Andrey last weekend. I played custom maps only. It *partially* works but sometimes something breaks very bad. At a point no (or only a very few, dunno) users could join my hosted game, a friend of mine who wanted to do so became an error message. Another thing: During a game one guy lagged and shortly after he left all other players did so too, but not because they wanted :)

Unfortunately I did not look if I encountered a 24/h disconnect. That just came into my mind.. damn!

Any news about Andrey? Is he in vacation or did this bug bugged him away? :)

The problem still exists, in-game chat except from host can't be read and "bugged" games (e.g. those where the b.net menus fade out) don't give a timeout so you could continue.

Hosting also works only partially for me. Honestly, it is a real Wine 1.0 blocker. How can it be that Battle.Net in Warcraft III works fine with some unstable Wine version, and won't work with a stable 1.0 release. I mean, Warcraft III has been working for ages..

(In reply to comment #182)
> Hosting also works only partially for me. Honestly, it is a real Wine 1.0
> blocker. How can it be that Battle.Net in Warcraft III works fine with some
> unstable Wine version, and won't work with a stable 1.0 release. I mean,
> Warcraft III has been working for ages..
> 

I agree 100%.  WC3 BNET worked for ages without any problems. This is one of the most worse regression bugs in wine.

And i just want to mention that this bug has 52 Votes... 

Back when Wine 0.9 first was released, it was promised that regressions would be fixed between releases.

There's a lot of votes on this bug, and it is a regression which affects a number of users, since the people who vote for a bug are a small percentage of those who have problems with it (in my experience).

This is open source folks.  If one of you wants to step up and fix the bug, patches are always welcome.  If none of the 55 voters or CCs can fix the bug, you can all pool together enough money to hire a developer to implement the missing features.  I say that in all seriousness.  Adding comment #205 complaining about this bug won't change anything.

(In reply to comment #185)
> This is open source folks.  If one of you wants to step up and fix the bug,
> patches are always welcome.  If none of the 55 voters or CCs can fix the bug,
> you can all pool together enough money to hire a developer to implement the
> missing features.  I say that in all seriousness.  Adding comment #205
> complaining about this bug won't change anything.

I work on an Open Source project, and I'm always interested in fixing bugs, but I tend to give priority to the ones that seem to be affecting the most people.  I think that we're just trying to let the developers know it's affecting us so that they _may_ decide to prioritize it over other bugs.  Whether or not they do is entirely up to them.

For the magnitude and size of this project, we're sorely lacking developer resources.  We are very aware of this bug and the number of votes.  I'm positive that if a developer were available and looking for something to work on, this would be pretty high up on the list.

This is NOT a regression, it is only implementation of AcceptEx, which does not work as well as expected. (Read comments)

With "Disable completion port creation" patch (nr 8368) everything works like it worked in older Wines, but it removes this new feature.

(In reply to comment #188)
> This is NOT a regression, it is only implementation of AcceptEx, which does not
> work as well as expected. (Read comments)
> 
> With "Disable completion port creation" patch (nr 8368) everything works like
> it worked in older Wines, but it removes this new feature.
> 

Well IMHO regression is if something did work but doesn't anymore. Even if its because of a new feature...

It's not the only regression in WC3 since i cant tab to desktop (directX) or loose all textures (opengl) since 9.60. Yes i will report that regression.

And i don't want to blame people for not fixing this bug. I just cant understand why Andrey Turkin's patch should be in stable. Are there any benefits? 

There are other applications like Photoshop, Eve Online and Outlook 2007(not sure here) which need asynchronous IO.

(In reply to comment #190)
> There are other applications like Photoshop, Eve Online and Outlook 2007(not
> sure here) which need asynchronous IO.
> 

Well... WC3 also need that and it did work before. Or am i wrong?

WC3 obviously can use it if it is available, but it doesn't need it. Other apps refuse to run if IO Completion support isn't available.

I will also add that while playing a LAN game (through Hamachi VPN), I can usually only see the chat text of the host, and not anything from the other players, even though I confirmed that they were sending messages in game. (LAN games are different in that they do not go through Battle.net.)

I have, however, had the odd game where I could see more chat (in that case it was from another guy who was at the same real home network as the host).

I will test a real LAN game in a few days.

LAN works fine. Played yesterday a game with my brother, though it requires the host to have acceptex_v2 patched wine.

(In reply to comment #193)
> I will also add that while playing a LAN game (through Hamachi VPN), I can
> usually only see the chat text of the host, and not anything from the other
> players, even though I confirmed that they were sending messages in game. (LAN
> games are different in that they do not go through Battle.net.)

That is a known issue and belongs to bug 7327.
 
> I have, however, had the odd game where I could see more chat (in that case it
> was from another guy who was at the same real home network as the host).

Yes, that's expected. As already mentioned, playing in a real LAN works just fine.

Is it likely this will be fixed in wine 1.0 ?
i tried the second acceptx patch, it compiled fine but didn't really work.
so I'm using the " Disable completion port creation  " patch again

(In reply to comment #195)
> (In reply to comment #193)
> > I will also add that while playing a LAN game (through Hamachi VPN), I can
> > usually only see the chat text of the host, and not anything from the other
> > players, even though I confirmed that they were sending messages in game. (LAN
> > games are different in that they do not go through Battle.net.)
> 
> That is a known issue and belongs to bug 7327.

The same scenario works perfectly under Wine 0.9.45. I receive all chat messages. This is all related to AcceptEx?

Since it works perfectly on the older Wine, it is hardly caused by "a fundamental difference between the handling of broadcast messages between Windows and Linux" as you say in bug 7327. (though I have not tried Starcraft)

*** Bug 6858 has been marked as a duplicate of this bug. ***

*** Bug 280 has been marked as a duplicate of this bug. ***

Using Wine 1.0-rc2 I can connect to Battle.net and play custom games (dota). Haven't tried normal (random matchup) games, but this should work.

(In reply to comment #200)
> Using Wine 1.0-rc2 I can connect to Battle.net and play custom games (dota).
> Haven't tried normal (random matchup) games, but this should work.
> 

Well - sorry but why do you mention that? Please read the comments and understand the problem(s).

> Well - sorry but why do you mention that? Please read the comments and
> understand the problem(s).

From my understanding it is new that a relatively new Wine version from Winehq supports connecting to BNet without using one of the patches here. 


Why shouldn't have Carl mentioned it here? Sorry but this is not about your DotA problem only..

Did any one allready check hosting custom/non-custom b.net games wit wine-1.0-rc2 ??

(In reply to comment #203)
> Did any one allready check hosting custom/non-custom b.net games wit
> wine-1.0-rc2 ??
> 

Yes, B.Net itself works, Hosting doesn't, and I still can't read most of the chat in game. So no change to previous versions.

Wine-1.0 is in deep code freeze.  Deferring.

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?

acceptex unnofficial patch in deb package please!

(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...

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"???

(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.

(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.

(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.

(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.

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)

(In reply to comment #213)
We agree for parts one and two good!
> 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.
a) The wineserver itself is an asynchronous kernel.
b) I have noticed the missed connections too.
c) I think the wineserver is required to make a distinct listener thread to implement acceptex properly. The POSIX sockets cannot, and the exsiting wineserver socket implementation cannot, properly set the flags.
 
> 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.

Didn't think about the assigned socket thing. I think a correct acceptex implementation requires a distinct listener thread operated by the wineserver implemented in the form of an asynchronous accept function. Maybe not, but I think thats the whole point of the acceptex function in the first place.

(In reply to comment #215)
> a) The wineserver itself is an asynchronous kernel.
true
> b) I have noticed the missed connections too.
> c) I think the wineserver is required to make a distinct listener thread to
> implement acceptex properly. The POSIX sockets cannot, and the exsiting
> wineserver socket implementation cannot, properly set the flags.
> 
You still think it is required even if you think wineserver is an asynchronous? POSIX sockets can do non-blocking accept just the same way as non-blocking read/writes work; wineserver can emulate asynchronous read/write from non-blocking i/o, and it should be able to emulate asynchronous accept (and connect too). Existing mechanisms could be used for this. Not sure what you meant about flags, though.

(In reply to comment #214)
> 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:
> <snip>
> 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


I am witnessing almost identicle behavior.  When I get dropped is random (usually like 30 minutes in) but its pretty consistent, every game.

(In reply to comment #216)
> You still think it is required even if you think wineserver is an asynchronous?
> POSIX sockets can do non-blocking accept just the same way as non-blocking
> read/writes work; wineserver can emulate asynchronous read/write from
> non-blocking i/o, and it should be able to emulate asynchronous accept (and
> connect too). Existing mechanisms could be used for this. Not sure what you
> meant about flags, though.
> 
Hmm. Maybe I need to read more. What i meant by flags is actually handled by the completion ports paradigm Here is my program control flow idea.

main thread
>---AcceptEx----AcceptEx-----AcceptEx------WaitsOnCompletionPorts.  .-data in-->

Wineserver
    AcceptEx-. .-blocks for connect-.   blocks for buffer  .-signals compport-^
                AcceptEx----.   blocks for buffer  .-signals-^
                             AcceptEx----. Blocks                      .-signals-^

Here acceptex blocks for the socket to connect and blocks to read data off of the socket until the buffer is full, then it puts the data on the completion port. AcceptEx does not put data on the completionport until the buffer is full. Here acceptex is blocking inside of the wineserver, not the main thread (AcceptEx does not block the main thread until the thread waits on the completion ports). I was originally thinking that we needed to spawn threads in the wineserver, but if we already have non-blocking i/o then we can use those functions to do the blocking for the buffer like so:

Wineserver
    AcceptEx-. .-blocks for connect-. Non-BlockingI/OCall.
                                      Non-BlockingI/OCall----blocks for buffer.   .-signals completion port-^

Then we just need to be able to queue the Non-Blocking i/o call with the non-blocking accept. and The AcceptEx psudeo code looks like this:

AcceptEx
 Non-BlockingI/O-Read(Non-BlockingAccept);
 return IO_PENDING;

And we let the non-blocking i/o deal with signaling the completion port.

The reason why I think we need threads is that for the main thread to avoid being blocked, some other thread(inside the kernal) needs to be blocked in order to do the i/o waiting.

(sorry if the formating is bad)

(In reply to comment #216)

After working my way through more of the wineserver code I understand better that what you have implemented and what I have been thinking is similar. The threads I was thinking about are pre-built into the wineserver utilizing the async register and callbacks. Please forgive my ignorance regarding that. There is a lot of code here to sort through.

*Note: I am making these changes and testing as I am writing this, but it takes for ever to compile on my laptop and test. I will post results as I have them.


Regarding the missing connections (or the apparently missed connections), they could originate from the lack of implementing data_len correctly or status messages getting lost somewhere. For instance, as the patch is written:

+static NTSTATUS WS2_async_accept(void* user, IO_STATUS_BLOCK* iosb, NTSTATUS status)
... Edited for relevance
+    case STATUS_ALERTED:
+        SERVER_START_REQ( accept_socket )
+        {
................
+            status = wine_server_call( req );
+        }
+        SERVER_END_REQ;
+
+        if (!status)
+        {
+            status = AcceptEx_recv( ......);
+        }

The accept_socket function will only return NULL or 0 or FALSE when the accept_socket call fails, thus the AcceptEx_recv function is being called when there is accept function fails, which I believe is the incorrect behavior. I believe it should re-queue itself in the async queue due to the multi-threaded nature of the system. (I also believe the accept should be made atomic with mutex's but I don't know if thats implemented elsewhere or not in the async_queue functions or not).

The AcceptEx_recv call should happen inside of the else case of the if(!status), something like this:

if(!status)
 requeue
else
 acceptex_recv

It is also possible that the acceptex_recv should be done asynchronously itself, and the windows error stack should not be updated until after the data is received.

(In reply to comment #219)
> Regarding the missing connections (or the apparently missed connections), they
> could originate from the lack of implementing data_len correctly or status
> messages getting lost somewhere. For instance, as the patch is written:
> 
> +static NTSTATUS WS2_async_accept(void* user, IO_STATUS_BLOCK* iosb, NTSTATUS
> status)
> ... Edited for relevance
> +    case STATUS_ALERTED:
> +        SERVER_START_REQ( accept_socket )
> +        {
> ................
> +            status = wine_server_call( req );
> +        }
> +        SERVER_END_REQ;
> +
> +        if (!status)
> +        {
> +            status = AcceptEx_recv( ......);
> +        }
> 
> The accept_socket function will only return NULL or 0 or FALSE when the
> accept_socket call fails, thus the AcceptEx_recv function is being called when
> there is accept function fails, which I believe is the incorrect behavior. I
You are mixing up accept_socket function and accept_socket handler. accept_socket return either NULL in case of error, or object in case of success. accept_socket handler, though, returns NTSTATUS just like all other handlers, so !status is true when and only when status is STATUS_SUCCESSFUL (which is equal to 0). AcceptEx_recv gets called only after successful accept.
> believe it should re-queue itself in the async queue due to the multi-threaded
> nature of the system. (I also believe the accept should be made atomic with
> mutex's but I don't know if thats implemented elsewhere or not in the
> async_queue functions or not).
and the socket gets queued (at this point it should not have been in queue already, so not re-queued but queued) if accept_socket fails with EWOULDBLOCK.
Worry no about mutexes and synchronization etc - wineserver _is not_ multithreaded, there can be no two simultaneous requests. wineserver essentially runs in big loop, reading and executing one request at the time.
> It is also possible that the acceptex_recv should be done asynchronously
> itself, and the windows error stack should not be updated until after the data
> is received.
Totally agree, it should be! Unfortunately, currently async code in wineserver does not allow restarting request after server->client call, or attaching same request to another fd, which is necessary to correctly implement AcceptEx (and also do the same for TransmitFile/TransmitPackets and maybe some other advanced i/o functions)

AcceptEx initial functionality has been added to main tree by the following patch, please test and close this issue.
http://source.winehq.org/git/wine.git?a=commitdiff;h=2da98052d90591474c65bed853ca75e1da714823

Who's the author? I'll kiss him all over if this works :)

Or better let's leave it at giving a beer ;)

Sorry guys, that isn't the AcceptEx, Jon Griffiths submitted this as part of his TransmitFile/TransmitPackets implementation. This is merely forward to ws2_32, acceptex implementation there is stubbed yet so no changes yet...

(In reply to comment #224)
> Sorry guys, that isn't the AcceptEx, Jon Griffiths submitted this as part of
> his TransmitFile/TransmitPackets implementation. This is merely forward to
> ws2_32, acceptex implementation there is stubbed yet so no changes yet...
> 

I haven't had time to throughly test it, but I believe that the correct implementation for AcceptEx (only accepting the connection, no data yet) is to set the error message to STATUS_PENDING instead of WSAWOULDBLOCK and then using add_completion immediately after (or in) the acceptex_recv function. Doing one or the other seems to cause fatal errors, doing both, however, seems to have the desired result (and from what I can tell, the missed connection problem goes away too). If i can work out how to make a patch I will test more and post one here the day after tomorrow. (work interferes)

Created attachment 14986 [details]
Partial AcceptEx impelementation. - Still Buggy

(In reply to comment #220)
> Totally agree, it should be! Unfortunately, currently async code in wineserver
> does not allow restarting request after server->client call, or attaching same
> request to another fd, which is necessary to correctly implement AcceptEx (and
> also do the same for TransmitFile/TransmitPackets and maybe some other advanced
> i/o functions)

Git and patch sets hurt my brain. I finally got it all setup into one patch for you if you are interested. I borrowed heavily from what you had (if its not broken don't fix it), but I went about AcceptEx and WS2_async_accept functions differently. My patch works for a period of time before some critical event happens. I don't know what it is (yet) but I know it has to do with reusing the accept sockets and the overlapped data structure. Once the critical event happens nothing particularly interesting happens. The sockets that are in queue get dequeued and error off the winestack, and then the program acts like acceptex isn't implemented. I have had segfaults, but those happento the latest git branch, which seems to segfault randomly even without any patches applied.

War3 players. It should work for one game, maybe two, if war3 errors out when you join a game (not when the game starts) let me know (and if you have a trace that would be nice).

Created attachment 15080 [details]
AcceptEx impementation. No data_len support. Messy code.

This AcceptEx implementation works as far as I can tell. I haven't written any test cases yet, but it is much more robust than the previous patch. When playing warcarft 3 b.net games, you will be able to join/create multiple games and send/receive chat from other players.

(In reply to comment #227)

> This AcceptEx implementation works as far as I can tell. I haven't written any
> test cases yet, but it is much more robust than the previous patch. When
> playing warcarft 3 b.net games, you will be able to join/create multiple games
> and send/receive chat from other players.

If that patch is working for other people as well, could you clean it up and submit to the wine-patches mailing list?

As part of the cleanup, please remove the C++ style comments // and replace them by C style comments.

(In reply to comment #228)
> (In reply to comment #227)
> 
> > This AcceptEx implementation works as far as I can tell. I haven't written any
> > test cases yet, but it is much more robust than the previous patch. When
> > playing warcarft 3 b.net games, you will be able to join/create multiple games
> > and send/receive chat from other players.
> 
> If that patch is working for other people as well, could you clean it up and
> submit to the wine-patches mailing list?
> 
> As part of the cleanup, please remove the C++ style comments // and replace
> them by C style comments.
> 

Need other people to test it.

So, other people, give it a shot!

(In reply to comment #229)
> 
> Need other people to test it.
> 
> So, other people, give it a shot!
> 

Hi,

everything worked fine so far, except that I had to restart Warcraft III after hosting one game and before hosting another.
When hosting the second game it seemed that the behaviour was quite the same as without the patch: No connections were accepted.

(In reply to comment #227)
> Created an attachment (id=15080) [details]
> AcceptEx impementation. No data_len support. Messy code.
> 
> This AcceptEx implementation works as far as I can tell. I haven't written any
> test cases yet, but it is much more robust than the previous patch. When
> playing warcarft 3 b.net games, you will be able to join/create multiple games
> and send/receive chat from other players.
> 

i'll test the patch in the next days, but THANK YOU!
this is one of the most annoying bugs in wine, and it's open since.. forever.

Created attachment 15135 [details]
log of warcraft running with wine-1.1.2 patched with http://bugs.winehq.org/attachment.cgi?id=15080

Thank you for your work!

I can confirm that you can host one game without any problems.
At the second try no one will be able to join.
One player who wanted to join told me that he get after about 10 seconds a message, that the game could not be found. This message usually only appear if a user tries to join a game when the host has canceled hosting.

I attached a log of this Warcraft 3 session. It contains some lines about a "error in getting socket".

I compiled it with GIT tree from July, 28th 2008, 11:30. I hosted one game, without problems.

Output of WINEDEBUG=+sync,+winsock with latest patch 15080 can be downloaded from http://petoju.norunof.sk/logwarcraft.txt (30,7MB)

(In reply to comment #229)
> Need other people to test it.
> 
> So, other people, give it a shot!
> 
I found one problem so far: this code needs at least one async to be registered during connect. Would this be false, the connect would be noticed, pmask would be updated and new poll events would be suppressed. Easiest way to reproduce is:
1) create new socket, bind() it and listen() to it
2) connect to this socket
3) call AcceptEx
On Windows AcceptEx accepts the connection and sends completion message; with your patches connection never gets accepted and completion is never sent. With my patches this one works (because of first accept call you removed) but I think there are some similar bug. Existing asynchronous socket implementation (pmask/hmask/custom socket object functions) make things pretty complicated...

Created attachment 15156 [details]
ggclient log WINEDEBUG=+sync,+winsock

whops sorry forgot to add comment:

bnet works quite good! you just have to restart war3 to host again
i don't know if this is related or not, but garena doesn't work 

here's the story behind garena:

garena is a software for playing warcraft3 simulating lan game via p2p

it used to work, no acceptex needed
two months ago they rewrote some network functions (no changes in the protocol tho), and when you tried to connect it woudn't let you anymore saying you were behind a firewall due acceptex not implemented

with this patch i don't get the error message anymore but it still won't login

trace attached in the previous comment 

Created attachment 15164 [details]
AcceptEx General Patch - No data_length support

(In reply to comment #236)
Thank you for your trace. It helped me isolate the situation with closing sockets.
(In reply to comment #232)
I have resolved this issue. Thank you for your log, it was helpful.

(In reply to comment #234)
Thanks, fixed.

A big thank you to Andrey Turkin. Without your help I would never have gotten very far. Much of the original code for the patch came from Andrey, if you want someone to thank, thank him.


As for this patch, some notes: The problem with both my first patch and second patch attempt, and I believe part of the problem with Andrey's second patch, deals with the book keeping that is done by the wineserver core. Asynchronous I/O  necessitates that multi-threading happen. With the AcceptEx this is particularly tricky, because we have to keep track of two different sockets, that are doing different things. Our async queue is on the listening socket, but when the accepting socket is closed (without accepting a connection) the async queue needs to be updated to remove that socket from the listening socket's listening queue. This is where all of the "missing connections" went. We were accepting connections to sockets the host program thought it had closed. (This also caused all kinds of deadlocking issues in the background). Thus, a socket (or well, anything that is asynchronous) needs to know how to locate and destroy the async request that we are a part of, but we are not waiting on. (We wait on the listening socket, but we are not listening).

That being said, this patch does not solve all of the issues. I believe it solves the issues mentioned, but it doesn't solve all of the order/out of order problems. I just can't figure them all out.

Now might be a good time to write conformance tests that
poke at the behaviors you're still not sure of.

Created attachment 15165 [details]
AcceptEx General Patch - No data_length support

Right. Don't upload the wrong patch. -_-

(In reply to comment #238)
> Now might be a good time to write conformance tests that
> poke at the behaviors you're still not sure of.
> 

I know what is happening. I just don't know whats the best way to go about
fixing it. I will Illustrate.

I will treat the wineserver like a fifo for simplicity.

AcceptEx is called. Socket 0xA listens for connections. Socket 0xB will accept.

Wineserver: Not doing anything.

A connection attempt occurs. 

Wineserver: Notify(0xA)

Simultaneously CloseSocket is called on socket 0xB by the program thread and
the wineserver is asked to remove 0xB from 0xA's queue. Followed by destroying
0xB

WineServer: Destroy(0xB) -> Remove(0xB from 0xA queue) -> Notify(0xA)

The Notify occurs and the callback function is initiated. The callback function
asks the wineserver to connect on 0xA accepting to 0xB. The callback function
cannot know about the remove call.

WineServer: Connect(0xA to 0xB) -> Destroy(0xB) -> Remove(0xB from 0xA queue)

The remove happens, but the connect has been queued. The destroy happens, and
the connect is intialized, but fails because 0xB is destroyed.

The end result? Not much. The connection failed. If the connect happened before
the remove and destroy, the result would be the same. If the remove happend
first, the Notify would stall (or pass it on to the next AcceptEx accepting
socket). The only difference is the error message that gets passed to the
program... It can potentially overwrite program data (because when the connect
fails failure information is written to overlapped data structure which could
have been freed or reused by the program thread already).

Don't explain it to me; write a test case.  
You don't seem to understand the awesome power of conformance test
cases.  They are truly your friend.  Please write one.

(In reply to comment #239)
> Created an attachment (id=15165) [details]
> AcceptEx General Patch - No data_length support

The patch works great for Warcraft III. It is possible to host games without any problems! Thank you!

I hope you will be able to get this change committed soon. 

I would like to donate 5 € to you Scott and Andrey via Paypal. I am still a student, so I don't have much money, but the 5 € will be enough for some ice cream ;). So if you are interested you need to pass me somehow your paypal account name.

(In reply to comment #239)
> Created an attachment (id=15165) [details]
> AcceptEx General Patch - No data_length support
> 
> Right. Don't upload the wrong patch. -_-
> 

Now i can click on "Start game" on garena and the Warcraft starts... but, i can't see any games :\

(In reply to comment #243)
> Now i can click on "Start game" on garena and the Warcraft starts... but, i
> can't see any games :\

well with this last implementation of acceptEx i can see games in garena
so maybe this is not related (many people have problems seeing games in garena in windows too..)
too bad i can't try to play since join a game causes warcraft 3 to crash (graphic related, not network) in both opengl and d3d 
i'll try to downgrade nvidia-drivers with a stable version and see if it works.

(In reply to comment #244)
> (In reply to comment #243)
> > Now i can click on "Start game" on garena and the Warcraft starts... but, i
> > can't see any games :\
> 
> well with this last implementation of acceptEx i can see games in garena
> so maybe this is not related (many people have problems seeing games in garena
> in windows too..)
> too bad i can't try to play since join a game causes warcraft 3 to crash
> (graphic related, not network) in both opengl and d3d 
> i'll try to downgrade nvidia-drivers with a stable version and see if it works.
> 

in windows i see normally.... :\

(In reply to comment #245)
> in windows i see normally.... :\

yeah but it's very unlikely related to acceptex.. when garena worked without acceptex there were many dota players that had your same problem (they could see games from windows, but not from linux)
a friend of mine had the same problem, i routed his connection with a vpn on my pc and then he could see all the games
i'm not sure where is the problem here, but it's something not really obvious and network related

The ENTER key is not working to send message, I am having to click on the SEND button for the message to go .. and auto-scrolling of the chat is not working ..

(In reply to comment #247)
> The ENTER key is not working to send message, I am having to click on the SEND
> button for the message to go .. and auto-scrolling of the chat is not working
> ..
> 

This can't possibly have anything to do with this patch.
You probably have some key stuck or something like that...

(In reply to comment #246)
> (In reply to comment #245)
> > in windows i see normally.... :\
> 
> yeah but it's very unlikely related to acceptex.. when garena worked without
> acceptex there were many dota players that had your same problem (they could
> see games from windows, but not from linux)
> a friend of mine had the same problem, i routed his connection with a vpn on my
> pc and then he could see all the games
> i'm not sure where is the problem here, but it's something not really obvious
> and network related
> 

Garena wersions before 2.4 had some different networking mechanism, so it didn't needed AcceptEX... I think it was some "Advanced Mode" or something like that...

Anyway, i also get wc3 crash and to see a game i need to login to garena, then logout again and login again... This logout causes to run new task of Garena.exe so there are 2 processes... One propably zombie, bot ONLY this way, with 2 processes of garena (one unresponsive / zombie) i am able to see games... If i kill that i cannot see a game anymore...

Btw, when i try to join a game i get crash same as ksn...

This is a little hard to explain, so if i can provide mor information, let me know...

(In reply to comment #249)

> Garena wersions before 2.4 had some different networking mechanism, so it
> didn't needed AcceptEX... I think it was some "Advanced Mode" or something like
> that...

enhanced mode... i think it's default now..
with garena before 2.4 i could see games only with enhanced mode activated, without it i couldn't see any game
since 2.4 i can see games even if i can't select enhanced anymore...
a friend of mine told me that you can play with old garena too... you just have to block the auto update, setting a newer version on the xml file 
so i think that the network mechanism is still the same

> 
> Anyway, i also get wc3 crash and to see a game i need to login to garena, then
> logout again and login again... This logout causes to run new task of
> Garena.exe so there are 2 processes... One propably zombie, bot ONLY this way,
> with 2 processes of garena (one unresponsive / zombie) i am able to see
> games... If i kill that i cannot see a game anymore...
> 
> Btw, when i try to join a game i get crash same as ksn...
> 
> This is a little hard to explain, so if i can provide mor information, let me
> know...
> 

i don't think this is related, but yes something strange is going on
maybe the best solution for now is really to block the update and play with the older version

> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > I think i have got it......
> > Open garena, login anbd go to some channel. Then do menu - login as another  > > user and log again....
> > click on play and you can see the games....
> > DO it also crash for you when you want to join a game?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >


i make it, and now i see games, but i get crash here too when i try join in same game.. (Crash on Warcraft III)

(In reply to comment #251)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > I think i have got it......
> > > Open garena, login anbd go to some channel. Then do menu - login as another  > > user and log again....
> > > click on play and you can see the games....
> > > DO it also crash for you when you want to join a game?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> 
> 
> i make it, and now i see games, but i get crash here too when i try join in
> same game.. (Crash on Warcraft III)
> 

I need trace logs and if you have a core dump, a core dump from the war3 crashes.
(In reply to comment #242)
> I would like to donate 5 € to you Scott and Andrey
Hah, thanks, but no donations (to me) are necessary.

Created attachment 15226 [details]
log asked by slindeneau WINEDEBUG=+sync,+winsock wine garena.exe >& outlogfilename.txt

(In reply to comment #253)
> Created an attachment (id=15226) [details]
> log asked by slindeneau WINEDEBUG=+sync,+winsock wine garena.exe >&
> outlogfilename.txt
> 

It appears that AcceptEx is behaving normally. The only AcceptEx related calls that are shown are, as far as i can tell, correct. The program is opening and closing them with nobody connecting to them. Maybe this is a gateway/routing problem. garena creates a special gateway for lan traffic to go through so you can play lan games over it. You may need to have or change linux routing information. How, or what, i don't know. Check the Wine AppDB page for frozen throne under the Multiplayer Setup section.

(In reply to comment #254)
> (In reply to comment #253)
> > Created an attachment (id=15226) [details] [details]
> > log asked by slindeneau WINEDEBUG=+sync,+winsock wine garena.exe >&
> > outlogfilename.txt
> > 
> 
> It appears that AcceptEx is behaving normally. The only AcceptEx related calls
> that are shown are, as far as i can tell, correct. The program is opening and
> closing them with nobody connecting to them. Maybe this is a gateway/routing
> problem. garena creates a special gateway for lan traffic to go through so you
> can play lan games over it. You may need to have or change linux routing
> information. How, or what, i don't know. Check the Wine AppDB page for frozen
> throne under the Multiplayer Setup section.
> 

All ports required are opened.. i get FATAL ERROR when try join in any game on LAN (with garena) and sometime i can't see any games...

1513 to Garena and 6112-6119 to Warcraft III

(In reply to comment #255)
> All ports required are opened.. i get FATAL ERROR when try join in any game on
> LAN (with garena) and sometime i can't see any games...
> 
> 1513 to Garena and 6112-6119 to Warcraft III
> 

Post a trace log WINEDEBUG=+sync,+winsock and if you can post a core dump as well that would be helpful.

(In reply to comment #256)
> (In reply to comment #255)
> > All ports required are opened.. i get FATAL ERROR when try join in any game on
> > LAN (with garena) and sometime i can't see any games...
> > 
> > 1513 to Garena and 6112-6119 to Warcraft III
> > 
> 
> Post a trace log WINEDEBUG=+sync,+winsock and if you can post a core dump as
> well that would be helpful.
> 

i don't know what program i need to get this log...

(In reply to comment #257)
> (In reply to comment #256)
> > (In reply to comment #255)
> > > All ports required are opened.. i get FATAL ERROR when try join in any game on
> > > LAN (with garena) and sometime i can't see any games...
> > > 
> > > 1513 to Garena and 6112-6119 to Warcraft III
> > > 
> > 
> > Post a trace log WINEDEBUG=+sync,+winsock and if you can post a core dump as
> > well that would be helpful.
> > 
> 
> i don't know what program i need to get this log...


http://wiki.winehq.org/FAQ#head-a37de3282d447376d2220d20a278ae52258551a4

Created attachment 15523 [details]
General AcceptEx Patch - No Data_length Support

I have updated the patch fixing a number of fringe issues. One of the issues I have fixed involves a hanging issue that sounds similar to the issue the garena people have described. I would like some of the garena people to try this new patch and tell me if it helps. (The issue didn't cause any errors or noticeable patterns in the traces.)

I am working to get these patches up to snuff and upstream into the wine source for the next version (or maybe the one after that).

Short: garena people, try this. Tell me if it works.

(In reply to comment #259)
> Created an attachment (id=15523) [details]
> General AcceptEx Patch - No Data_length Support
> 
> I have updated the patch fixing a number of fringe issues. One of the issues I
> have fixed involves a hanging issue that sounds similar to the issue the garena
> people have described. I would like some of the garena people to try this new
> patch and tell me if it helps. (The issue didn't cause any errors or noticeable
> patterns in the traces.)
> 
> I am working to get these patches up to snuff and upstream into the wine source
> for the next version (or maybe the one after that).
> 
> Short: garena people, try this. Tell me if it works.
> 

I will try this as soon as i can, but if this works you are my personal hero :)

Patch works like a charm (for hosting and chatting)!
Maybe l8er I will test it with Garena.

(In reply to comment #259)
> Created an attachment (id=15523) [details]
> General AcceptEx Patch - No Data_length Support
> 
> I have updated the patch fixing a number of fringe issues. One of the issues I
> have fixed involves a hanging issue that sounds similar to the issue the garena
> people have described. I would like some of the garena people to try this new
> patch and tell me if it helps. (The issue didn't cause any errors or noticeable
> patterns in the traces.)
> 
> I am working to get these patches up to snuff and upstream into the wine source
> for the next version (or maybe the one after that).
> 
> Short: garena people, try this. Tell me if it works.
> 

my garena still hangs, and i really don't think it's acceptex related
tell me if you need something to debug more

(In reply to comment #261)
> Patch works like a charm (for hosting and chatting)!
> Maybe l8er I will test it with Garena.
> 


I can confirm this, hosting & chatting is functional. Is yet to see if my game will freeze after X hours of gameplay (.45 in combination with warcraft3 1.22 had this nasty combination which caused a complete freeze).

this patch for me is really stable... i have like 80+ hours of bnet and no problems! 

any luck having this patch accepted?

failing that, does anyone have a deb of current/recent wine with this patch applied?

(In reply to comment #265)
> any luck having this patch accepted?
> 
> failing that, does anyone have a deb of current/recent wine with this patch
> applied?
> 

No luck so far. The patch does technically break something according to the design of the wineserver so I have had to rewrite a bunch of code. The current design is failing a test I can't reproduce. I will see if I can get it fixed. Even after I get everything fixed it might take a while to get upstream. The patch is more than 1000 lines in length and things like that don't get magically adapted right away (as unfortunate as that may seem).

Thanks for your patience, I wouldn't have so much ;-)

(In reply to comment #265)
> any luck having this patch accepted?
> 
> failing that, does anyone have a deb of current/recent wine with this patch
> applied?
> 

I do not have a deb, but i do have a FC8 rpm - perhaps you can convert it (if you don't want to build it yourself)?
http://dailyupload.net/Files/Wine/

I'm using the newest patch now for a month or so and today the game crashed with critical section errors:

fixme:imm:ImmReleaseContext (0x3002c, 0x130740): stub
fixme:imm:ImmGetOpenStatus (0x130740): semi-stub
fixme:imm:ImmGetOpenStatus (0x130740): semi-stub
fixme:imm:ImmGetOpenStatus (0x130740): semi-stub
fixme:winsock:WS2_async_accept error in getting socket. socket: 41a4, status: 2733
err:ntdll:RtlpWaitForCriticalSection section 0x4982d34 "?" wait timed out in thread 0035, blocked by 0000, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x4982d34 "?" wait timed out in thread 0035, blocked by 0000, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x4982d34 "?" wait timed out in thread 0035, blocked by 0000, retrying (60 sec)

The errors started appearing while I was playing and I managed to finish my game witout a problem, however after that the game crashed as I tried to quit.

(In reply to comment #269)
> I'm using the newest patch now for a month or so and today the game crashed
> with critical section errors:
> 
> fixme:imm:ImmReleaseContext (0x3002c, 0x130740): stub
> fixme:imm:ImmGetOpenStatus (0x130740): semi-stub
> fixme:imm:ImmGetOpenStatus (0x130740): semi-stub
> fixme:imm:ImmGetOpenStatus (0x130740): semi-stub
> fixme:winsock:WS2_async_accept error in getting socket. socket: 41a4, status:
> 2733
> err:ntdll:RtlpWaitForCriticalSection section 0x4982d34 "?" wait timed out in
> thread 0035, blocked by 0000, retrying (60 sec)
> err:ntdll:RtlpWaitForCriticalSection section 0x4982d34 "?" wait timed out in
> thread 0035, blocked by 0000, retrying (60 sec)
> err:ntdll:RtlpWaitForCriticalSection section 0x4982d34 "?" wait timed out in
> thread 0035, blocked by 0000, retrying (60 sec)
> 
> The errors started appearing while I was playing and I managed to finish my
> game witout a problem, however after that the game crashed as I tried to quit.
> 

Have you recently updated git?

(In reply to comment #270)
> (In reply to comment #269)
> > I'm using the newest patch now for a month or so and today the game crashed
> > with critical section errors:
> > 
> > fixme:imm:ImmReleaseContext (0x3002c, 0x130740): stub
> > fixme:imm:ImmGetOpenStatus (0x130740): semi-stub
> > fixme:imm:ImmGetOpenStatus (0x130740): semi-stub
> > fixme:imm:ImmGetOpenStatus (0x130740): semi-stub
> > fixme:winsock:WS2_async_accept error in getting socket. socket: 41a4, status:
> > 2733
> > err:ntdll:RtlpWaitForCriticalSection section 0x4982d34 "?" wait timed out in
> > thread 0035, blocked by 0000, retrying (60 sec)
> > err:ntdll:RtlpWaitForCriticalSection section 0x4982d34 "?" wait timed out in
> > thread 0035, blocked by 0000, retrying (60 sec)
> > err:ntdll:RtlpWaitForCriticalSection section 0x4982d34 "?" wait timed out in
> > thread 0035, blocked by 0000, retrying (60 sec)
> > 
> > The errors started appearing while I was playing and I managed to finish my
> > game witout a problem, however after that the game crashed as I tried to quit.
> > 
> 
> Have you recently updated git?

No, I'm using 1.1.4.
> 

(In reply to comment #271)
> No, I'm using 1.1.4.

That's a new git since the patch(patch was 1.1.2)... But I think I know what the problem is, and it's not related to the git update.

<insert note to self>
The incoming connection hangs up(closes) before the dll thread can process the connection. This results in incorrect behavior for AcceptEx which incorrectly notifies that a socket is ready for use, when it's not. This incorrectly initialized socket is then used in other asynchronous socket functions which causes the critical wait errors.

Fix: Do not use the completion mechanism built into the register_async. Only add-completion upon successful connection of a socket. Socket should requeue itself instead of returning the failure.
<end note to self>

In-Game messages from other players than host does not work in 1.1.5. Previously, I had 1.1.2 before 1.1.5 and it worked, so it is possible regression.

(In reply to comment #273)
> In-Game messages from other players than host does not work in 1.1.5.
> Previously, I had 1.1.2 before 1.1.5 and it worked, so it is possible
> regression.
> 

for me they didn't ever work without patch...

Hi sorry to spam post again...

can someone advise the status of this bug and patches so far?

I am still using a very old version ~.57 or so as this bug blocks me from upgrading wine. From posts, I assume the bug is still present in 1.1.5? 

thx jan

I confirm that this bug remains in 1.1.5 :(

(In reply to comment #275)
> Hi sorry to spam post again...
> 
> can someone advise the status of this bug and patches so far?
> 
> I am still using a very old version ~.57 or so as this bug blocks me from
> upgrading wine. From posts, I assume the bug is still present in 1.1.5? 
> 
> thx jan
> 

Check the patch here, http://bugs.winehq.org/attachment.cgi?id=15523 , it works for me, and some others (1.1.4 thou).
But you will still need to apply it yourself..

I think it may be worth noting that bug #11188 (most attempts to save result in a crash) suggests that the problem is caused by I/O completion port support, and they suggest using http://bugs.winehq.org/attachment.cgi?id=8368 to solve the issue. I will be trying the most recent patches here as well over this weekend.

Chat in Warcraft 3 works with wine 1.1.5 and I/O completion patch applied.
Yeeaaahh ;)

FWIW, there's a solaris patch here:
https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk/patches/wine-05-acceptex.diff

I've contacted the author, as he's written a few Solaris/Wine patches, so hopefully we can get them into mainline.

Patch 15523 is not accepting for me right in current GIT... Log follows:

gryffus@gryffus:~/wine-git> patch -p1 < acceptex.patch 
patching file dlls/mswsock/mswsock.spec
patching file dlls/ws2_32/socket.c
Hunk #1 succeeded at 192 with fuzz 1 (offset -2 lines).
Hunk #2 succeeded at 246 (offset 1 line).
Hunk #3 succeeded at 1077 (offset 1 line).
patching file dlls/ws2_32/ws2_32.spec
patching file include/wine/server_protocol.h
Hunk #4 succeeded at 4369 (offset 30 lines).
Hunk #5 succeeded at 4459 (offset 30 lines).
Hunk #6 succeeded at 4612 (offset 32 lines).
Hunk #7 succeeded at 4702 (offset 32 lines).
Hunk #8 succeeded at 4853 (offset 34 lines).
Hunk #9 succeeded at 4943 (offset 34 lines).
Hunk #10 FAILED at 5045.
1 out of 10 hunks FAILED -- saving rejects to file include/wine/server_protocol.h.rej
patching file server/async.c
patching file server/fd.c
patching file server/file.h
patching file server/protocol.def
patching file server/request.h
Hunk #3 succeeded at 397 (offset 2 lines).
Hunk #4 succeeded at 487 (offset 2 lines).
patching file server/sock.c
patching file server/trace.c
Hunk #4 succeeded at 3855 (offset 20 lines).
Hunk #5 succeeded at 3945 (offset 20 lines).
Hunk #6 succeeded at 4094 (offset 22 lines).
Hunk #7 succeeded at 4185 (offset 22 lines).
Hunk #8 succeeded at 4333 (offset 24 lines).
Hunk #9 succeeded at 4423 (offset 24 lines).


compile log (end):

make[2]: Entering directory `/home/gryffus/wine-git/dlls/ws2_32'
../../tools/winebuild/winebuild -w --def -o libws2_32.def --export ./ws2_32.spec
./ws2_32.spec:122: 'AcceptEx' redefined
./ws2_32.spec:120: First defined here
./ws2_32.spec:123: 'GetAcceptExSockaddrs' redefined
./ws2_32.spec:121: First defined here
make[2]: *** [libws2_32.def] Error 1
make[2]: Leaving directory `/home/gryffus/wine-git/dlls/ws2_32'
make[1]: *** [ws2_32/libws2_32.def] Error 2
make[1]: Leaving directory `/home/gryffus/wine-git/dlls'
make: *** [dlls] Error 2

Also let me add that when you host a game only one user can download it at a time. For some reason if two people start downloading the game simulatenous it just fails (for example You host a game someone joins and starts downloading and the percentage level goes up. However as more people join they don't start downloading (this happens in windows too). When the first downloader is finished a second, third, fourth should start (however many queued people there are). However in the current AcceptEx patch. If there is more than one person to wait for a download to start, it fails to start for everyone... Only when all but one downloaders leave, then the remaining starts downloading the map. 

So where would one start if they decided to try and tackle this? Which patches and what git revision?

I have submitted a number of working patches to the wine-patches. All of them heavily edit the wineserver core to fix a race condition that I cannot fix otherwise. All of my patches were rejected because they modify the wineserver more than they 'should'. I stopped developing the patch because I do not know how to fix the race condition without editing the wineserver (because the wineserver does not behave as I have been told it does. I submitted a report and sample code explaining the situation and never received a response.) If you want to try to write your own patch I can provide you with a patch that will work in all situation except in near simultaneous connections, which will result in a race condition (and will eventually cause the application to crash or hang).

(In reply to comment #284)
> (because the
> wineserver does not behave as I have been told it does. I submitted a report
> and sample code explaining the situation and never received a response.) 

Can you please provide a link to that report?

(In reply to comment #285)
> (In reply to comment #284)
> > (because the
> > wineserver does not behave as I have been told it does. I submitted a report
> > and sample code explaining the situation and never received a response.) 
> 
> Can you please provide a link to that report?
> 

http://www.winehq.org/pipermail/wine-patches/2008-September/060838.html

http://www.winehq.org/pipermail/wine-patches/2008-September/060997.html

Created attachment 16747 [details]
Fixed patch for 1.1.6

Same patch updated to cleanly apply to 1.1.6

(In reply to comment #287)
> Created an attachment (id=16747) [details]
> Fixed patch for 1.1.6
> 
> Same patch updated to cleanly apply to 1.1.6
> 

Does this patch for 1.1.6 include former patch 8297 and 8368 above?

I'm having an issue with random "FATAL ERROR" crashes and it was recommended that that I try patch 8368. I just downloaded the latest git and tried to apply it, but I got some error or another (I apologize I didn't write it down).

I saw the new patch listed here for 1.1.6 and tried it out. Built just fine and the game runs, but I still seem to get the error. Wasn't sure if this was because I wasn't applying the right patch or whether this just has nothing to do with my problem.

rebased patch at:
http://repo.or.cz/w/wine/hacks.git?a=commitdiff_plain;h=patches/master/winsock_acceptex

Thanks Jan,

I always appreciate your work with the hacks.git

Changing Version-Field to reflect that this bug first appeared in version 0.9.46 .

Where is the problem with accepting this into GIT so we can finally close this??

(In reply to comment #292)
> Where is the problem with accepting this into GIT so we can finally close
> this??
> 


------- Comment  #284 From Scott Lindeneau  2008-10-14 08:25:02 -------
... All of my patches were rejected because they modify the wineserver
more than they 'should'. I stopped developing the patch because I do not know
how to fix the race condition without editing the wineserver. ...

tonigths git build - still not repaired :( 

(In reply to comment #293)
> (In reply to comment #292)
> > Where is the problem with accepting this into GIT so we can finally close
> > this??
> > 
> 
> 
> ------- Comment  #284 From Scott Lindeneau  2008-10-14 08:25:02 -------
> ... All of my patches were rejected because they modify the wineserver
> more than they 'should'. I stopped developing the patch because I do not know
> how to fix the race condition without editing the wineserver. ...
> 

And Alexandre cannot provide some info how that can be resolved without modifying the wineserver? What he means by "more than should"?

Regards
          Gryffus

It's not easy to do this right.

How 'bout the users who want this start a
campaign to donate $5K or so to the Wine Party Fund,
with the stipulation that it be used to fix this
bug?  That would let Alexandre devote a week 
nonstop to integrating and testing the bugfix,
which might do the trick.  (I think he's going to
hate me for suggesting it :-)

>And Alexandre cannot provide some info how that can be resolved without
>modifying the wineserver? What he means by "more than should"?

There is a lot of code that gets modified. A Lot.

The basic patch is just under 300 lines of code. The code with the modified wineserver is over 1000. Check the file sizes. Andrey Turkin's code is the basic implementation. Just over 11KB. My partial is only a little over 16KB. Then once I figured out how to modify the wineserver it jumps to over 36KB.

Here is the basic problem. 
1) Alexander believes The wineserver works.
2) The wineserver does work, for everything until this point.
3) A new feature is added and it doesnt work because something doesn't work as specified.

Essentially, I, a relative unknown, am telling someone who has been working on this a long time that something is broken. If a man came in off the street and said that your product is broken, you don't always take him in hand and say he is right.

Under the hood:
The wineserver has an asynchronous operation structure in place. When an asynchronous command finishes, the next one is queued to start. This is what is supposed to happen. It doesn't(for sockets). I don't have the foggiest idea why.
My solution was to rewrite a set of if statements that allows commands to be executed without waiting for previous statements to finish. It also allows for random removal of events from the queue. This breaks a paradigm that the asynchronous queue was built upon. Thus the patch is considered wrong.

The wineserver is so poorly documented that I didn't know I was breaking a paradigm when I did it. I thought I was fixing it (from what comments are in the code). It happened to work, but it may be a case of 'I got lucky.' and I don't have strong evidence to support my case, other than "hey it works now".

Have test cases been written for all of these supposed deficiencies?

(In reply to comment #297)
> Essentially, I, a relative unknown, am telling someone who has been working on
> this a long time that something is broken. If a man came in off the street and
> said that your product is broken, you don't always take him in hand and say he
> is right.

If there's still doubt that there are errors in need of fixing, can't a regression test be used to prove this one way or the other?  Run the test on the unpatched version, then compare with the results from the patched version.

> This breaks a paradigm that the
> asynchronous queue was built upon. Thus the patch is considered wrong.
> 
> The wineserver is so poorly documented that I didn't know I was breaking a
> paradigm when I did it.

Do you think it would be worth it to submit a documentation patch that documents what the wineserver is actually doing, and not what it is designed to do?  It might at least enable developers who know the undocumented paradigms to focus on a fix that works within wineserver's intended design.

(In reply to comment #296)
> How 'bout the users who want this start a
> campaign to donate $5K or so to the Wine Party Fund,
> with the stipulation that it be used to fix this
> bug?

Be careful.  While some developers may appreciate a bounty-driven working environment that rewards them for focusing on what the community wants, others may find it either insulting, or at least reflective of a misunderstanding of why a given bug hasn't been fixed.  You may want to ask a more general question of what you can do to help the developers fix the problem.

(In reply to comment #300)

> Be careful. 

Just as a heads up who you're talking to right now:
http://www.winehq.org/?issue=346#WWN Wine 1.0 Interview Series Part 1, Dan Kegel

(In reply to comment #301)
> (In reply to comment #300)
> 
> > Be careful. 
> 
> Just as a heads up who you're talking to right now:
> http://www.winehq.org/?issue=346#WWN Wine 1.0 Interview Series Part 1, Dan
> Kegel
> 

http://wiki.winehq.org/AlexandreJulliard
"The enigmatic Alexandre Julliard, who has been in the project since its beginning in early 1993, has worked on and maintained the official Wine source ever since Bob Amstadt turned the helm over to him quite early. Although he enforces strict control over the official source tree (thus ensuring that every change must pass his scrutiny), nobody questions his abilities as the project leader, his commitment to quality, and his dedication to the Wine project; many 'disadvantageous' patches have been avoided by his strict quality control."

(In reply to comment #301)
> Just as a heads up who you're talking to right now:
> http://www.winehq.org/?issue=346#WWN Wine 1.0 Interview Series Part 1, Dan
> Kegel

Thanks, I didn't realize that Dan was a project member.

Dan, were you serious that it'll take $5,000 in donations to fix the problem in
a way that conforms to the wineserver's intended design?  That'd be about $54
for each of the 92 people who voted for this bug to be fixed, assuming everyone
pitched in.  That's certainly in the realm of what I'd consider paying to keep
Windows off my machine (I paid more over several years to Cedega until generic
wine started outperforming it) but not everyone will feel this way.

It might be even more expensive (say, $10K or $15K), but $5K would at least get Codeweavers' attention.  I don't think any bug has ever scraped $5K together though, so it's kind of a long shot.

(In reply to comment #304)
> It might be even more expensive (say, $10K or $15K), but $5K would at least get
> Codeweavers' attention.  I don't think any bug has ever scraped $5K together
> though, so it's kind of a long shot.

While Alexandre's development time surely deserves a high hourly rate, gathering this amount of money doesn't seem feasible.  Perhaps this is just a bug that will never be fixed due to the combined lack of affected users (92 users out of all the wine users) and the apparent time and effort required to architect an acceptable fix.

(In reply to comment #305)
> (In reply to comment #304)
> > It might be even more expensive (say, $10K or $15K), but $5K would at least get
> > Codeweavers' attention.  I don't think any bug has ever scraped $5K together
> > though, so it's kind of a long shot.
> 
> While Alexandre's development time surely deserves a high hourly rate,
> gathering this amount of money doesn't seem feasible.  Perhaps this is just a
> bug that will never be fixed due to the combined lack of affected users (92
> users out of all the wine users) and the apparent time and effort required to
> architect an acceptable fix.
> 

It'll be fixed at some point, surely. But Alexandre is busy fixing other things, and it's not on his todo list. Anywho, Bugzilla isn't the place for discussing these things. The best course of action would be to ask Alexandre again what is wrong with the wineserver code, the e-mail could've gotten lost in the shuffle.

(In reply to comment #306)
> (In reply to comment #305)
> > (In reply to comment #304)
> > > It might be even more expensive (say, $10K or $15K), but $5K would at least get
> > > Codeweavers' attention.  I don't think any bug has ever scraped $5K together
> > > though, so it's kind of a long shot.
> > 
> > While Alexandre's development time surely deserves a high hourly rate,
> > gathering this amount of money doesn't seem feasible.  Perhaps this is just a
> > bug that will never be fixed due to the combined lack of affected users (92
> > users out of all the wine users) and the apparent time and effort required to
> > architect an acceptable fix.
> > 
> 
> It'll be fixed at some point, surely. But Alexandre is busy fixing other
> things, and it's not on his todo list. Anywho, Bugzilla isn't the place for
> discussing these things. The best course of action would be to ask Alexandre
> again what is wrong with the wineserver code, the e-mail could've gotten lost
> in the shuffle.
> 

+1

(In reply to comment #305)
> (In reply to comment #304)
> > It might be even more expensive (say, $10K or $15K), but $5K would at least get
> > Codeweavers' attention.  I don't think any bug has ever scraped $5K together
> > though, so it's kind of a long shot.
> 
> While Alexandre's development time surely deserves a high hourly rate,
> gathering this amount of money doesn't seem feasible.  Perhaps this is just a
> bug that will never be fixed due to the combined lack of affected users (92
> users out of all the wine users) and the apparent time and effort required to
> architect an acceptable fix.
> 

I cannot agree with you... If this bug has 92 votes, it in any case doesnt mean, that it affects only 92 users...
Do you really think that every linux W3 player (there are hundred thousands or even more of them out there) has voted for this? And this affects ALL of them...
Creating LAN and Battle.net games is almost essential for playing... :-) Noone wants to create game for u for 1v1match and wait there until you finish (about 20min +-)...
Can you imagine that on local tournamenst, or even WCG (something as world game olypics) tournaments can be linux players? Or sponzored PCs with linux installed? No there cant and do u know why? Because of lacking AcceptEX...
I think that importance of this bug has been greatly underestimated... Importance not for wine itself, nor its developers, but importance for users.... And wine is for users isnt it?

My post isn't intended to offend anyone i'm just telling my view on this and i think every W3 player will agree with me.

Im sorry but i cannot help fix this, since i dont know anything of wineserver and i only develop in C# :-(

Best regards
Gryffus

Couldn't you make the changes for the que in the socket level and leave the wineserver alone?

Please, the bug tracking system is not a place for 
pleading for bug fixes, nor is it a place for
telling programmers how to do their jobs.  Let's
keep the noise level down, please.

(In reply to comment #310)
> Please, the bug tracking system is not a place for 
> pleading for bug fixes, nor is it a place for
> telling programmers how to do their jobs.  Let's
> keep the noise level down, please.
> 

nor is it a place to discuss funding.

would somebody mind describing how to apply this patch? do you have to completely recompile wine to get it to work? i'm a kubuntu user and have never compiled wine (or anything), can the patch be applied without re-compiling?

(In reply to comment #312)
> would somebody mind describing how to apply this patch? 

http://wiki.winehq.org/Patching

> do you have to completely recompile wine to get it to work?

yes

>Couldn't you make the changes for the que in the socket level and leave the
wineserver alone?

Short answer: no. Long answer: the sockets in the dll level don't have the necessary data structures and adding them would require modifying the wineserver.

I just thought it might be helpful for me to say that on a clean install of Ubuntu Intrepid, Warcraft III, and WINE 1.1.10 battle.net works flawlessly.  I have some other issues, but battle.net works 100% fine.

including hosting?

(In reply to comment #315)
> I just thought it might be helpful for me to say that on a clean install of
> Ubuntu Intrepid, Warcraft III, and WINE 1.1.10 battle.net works flawlessly.  I
> have some other issues, but battle.net works 100% fine.
> 

I'm sorry, I didn't realize my brother had gotten me a different version of WINE set up to work with Warcraft 3.  I believe I am already using the patch, nevermind.

*** Bug 14512 has been marked as a duplicate of this bug. ***

(In reply to comment #306)
> It'll be fixed at some point, surely. But Alexandre is busy fixing other
> things, and it's not on his todo list. Anywho, Bugzilla isn't the place for
> discussing these things. The best course of action would be to ask Alexandre
> again what is wrong with the wineserver code, the e-mail could've gotten lost
> in the shuffle.
> 

Actually the async I/O busy wait issue is on his 'TODO' list.

(In reply to comment #313)
> (In reply to comment #312)
> > would somebody mind describing how to apply this patch? 
> 
> http://wiki.winehq.org/Patching
> 
> > do you have to completely recompile wine to get it to work?
> 
> yes
> 
I was unable to patch 1.1.11.  I guess because the latest patch file attached to this bug is to patch 1.1.6.  do I need to revert to 1.1.6 in order to apply this patch?  Also, the instructions at "http://wiki.winehq.org/Patching" were extremely sparse and did not work for me.  the program "patch" needs a numeric argument to the -l command line argument, so I had to run this alternate command: patch -pl 1 < patch_file.

(In reply to comment #320)
> > 
> I was unable to patch 1.1.11.  I guess because the latest patch file attached
> to this bug is to patch 1.1.6.  do I need to revert to 1.1.6 in order to apply
> this patch?  Also, the instructions at "http://wiki.winehq.org/Patching" were
> extremely sparse and did not work for me.  the program "patch" needs a numeric
> argument to the -l command line argument, so I had to run this alternate
> command: patch -pl 1 < patch_file.
> 

You need a different font in your browser. The argument to patch is -p1 (minus p one), no l as in lambda in there.

Trying to use 1.1.6 patch for wine 1.1.12:
http://pastebin.com/f49a8ed13

btw: What's the current status? Any chances for AcceptEx to be in mainline?

My rebased version of Scott Lindeneau his patch ( http://repo.or.cz/w/wine/hacks.git?a=commitdiff_plain;h=patches/master/winsock_acceptex ) causes the following error on wine start:
wineserver: server/request.c:744: open_master_socket: Assertion `sizeof(union generic_request) == sizeof(struct request_max_size)' failed.

I'm replacing it with the disable iocp patch unless someone helps to fix that.

So Alexandre had fairly good reasons to not accept this patch into mainline :-)
Does he want this to be completely rewrited or just minor changes?
Any1 knows his opinion on this?
Thx

Regards
           Gfs

It needs 3 to 5 days of his time, I bet.  He's awful busy with other stuff. 

Ok so lets hope he will find some time for this... Thanx for the info...

        Gfs

Can anyone update the AcceptEx patch to work with 1.1.12? I still don't what stops this from getting into mainline. Is this not a commonly needed feature?

I'm outta here.  Too much noise from impatient users.

(In reply to comment #328)
> I'm outta here.  Too much noise from impatient users.
> 

Impatient? This is a _regression_ bug for nearly 15 month now.

Yes, this worked with earlier versions of wine - ingame chat and gamehosting.

Even if you dont read this - Alexandre accepted the "improvement" that broke this.

Martin

(In reply to comment #329)
> (In reply to comment #328)
> > I'm outta here.  Too much noise from impatient users.
> > 
> 
> Impatient? This is a _regression_ bug for nearly 15 month now.
> 
> Yes, this worked with earlier versions of wine - ingame chat and gamehosting.
> 
> Even if you dont read this - Alexandre accepted the "improvement" that broke
> this.
> 
> Martin
> 

As has been said dozens of times:

We know about the bug.

We know it's a major inconvenience.

We know it's a regression.


But all the comments are not going to fix it. Unless you're working on fixing the bug, please don't comment in this bug. All the comments just distract us from fixing bugs.

Wine is an open source project, not a paid for product that gives you the right to complain or direct resources. The source is available, you can fix it yourself, or find someone that can. Complaining in bugzilla, however, does neither.

(In reply to comment #323)
> My rebased version of Scott Lindeneau his patch (
> http://repo.or.cz/w/wine/hacks.git?a=commitdiff_plain;h=patches/master/winsock_acceptex
> ) causes the following error on wine start:
> wineserver: server/request.c:744: open_master_socket: Assertion `sizeof(union
> generic_request) == sizeof(struct request_max_size)' failed.
> 
> I'm replacing it with the disable iocp patch unless someone helps to fix that.
> 

Jan,

Does this mean that WINE compiles just fine and then throws this error upon invoking the command 'wine'?

D

Created attachment 18592 [details]
AcceptEx patch for 1.1.12

Please try if this patch works with 1.1.12 (it's just rebased version + fix to make request structure large enough for new requests)

Created attachment 18636 [details]
1.1.12 patch 1 hunk rejected

1 Hunk rejects from the rebased patch.

Created attachment 18638 [details]
AcceptEx patch for 1.1.12 (without autogenerated files)

Here is same patch without autogenerated files. Apply the patch and run tools/make_requests before compiling Wine.

Works fine now, thank you.

BTW, out of pure curiosity, could you explain to me what is the difference between the two patches (I'm noob at C)

1st version of 1.1.12 patch failed with 1 hunk too, new version applied just fine, but wine dont compile with it. I have x86_64. Build log: http://ok.undo.it/wine-acceptex.log

2Nicky:
> BTW, out of pure curiosity, could you explain to me what is the difference
between the two patches (I'm noob at C)
Wine uses some autogenerated files, and some of them are included in git/tarballs so that users do not need to regenerate them. The problem is that AcceptEx patch adds new wineclient-wineserver calls, i.e. modifies protocol.def file (protocol definition), and there are several c source and header files generated from it. With first patch version (with generated files) once somebody else change protocol.def files, not only changes in protocol.def must be merged, but also changes in few more machine-generated files must be merge too - thus problems with rejected hunks.
Second version does not include generated files, so merge succeeds but these generated files won't be updated until user run tools/make_requests to regenerate them.

2St.MPA3b
>1st version of 1.1.12 patch failed with 1 hunk too, new version applied just fine, but wine dont compile with it. I have x86_64. Build log: http://ok.undo.it/wine-acceptex.log

Nice nick :) From log it seems you forgot to invoke tools/make_requests . Just add "tools/make_requests || die" line as last line of src_unpack ebuild section.

(In reply to comment #334)
> Created an attachment (id=18638) [details]
> AcceptEx patch for 1.1.12 (without autogenerated files)
> 
> Here is same patch without autogenerated files. Apply the patch and run
> tools/make_requests before compiling Wine.
> 

Hello men!
Many thanks to Aleksey Turkin.
Patch works. I can host games in b.net. But I get one more trouble. Now, sound don`t work in warcraft, but still working in other programs on wine.
Am I the one, who get this? It seems very strange. And I feel stupid. :-)
And one more question, Why the official release do not include this patch?

(In reply to comment #338)
> And one more question, Why the official release do not include this patch?
> 

Read through all the comments.

> Hello men!
> Many thanks to Aleksey Turkin.
> Patch works. I can host games in b.net. But I get one more trouble. Now, sound
> don`t work in warcraft, but still working in other programs on wine.
> Am I the one, who get this? It seems very strange. And I feel stupid. :-)
> And one more question, Why the official release do not include this patch?
> 
yes, i finally got the patch to apply and to install the patched wine.  but then when i launched war3 I got the error pop-up: audio does not work.  when I launched winecfg the option for ALSA was removed and all I could pick was OSS, and that didn't work either.

(In reply to comment #340)
> yes, i finally got the patch to apply and to install the patched wine.  but
> then when i launched war3 I got the error pop-up: audio does not work.  when I
> launched winecfg the option for ALSA was removed and all I could pick was OSS,
> and that didn't work either.
> 

Are you sure you compiled wine with ALSA support after applying the patch? Also try compiling without the patch. My guess is you have been using a binary distribution before this patch.

Tested the patch on v1.1.12 and the invisible issues is fixed. 

(In reply to comment #342)
> Tested the patch on v1.1.12 and the invisible issues is fixed. 
> 

I meant the invisible chat issue is fixed ;)

(In reply to comment #343)
> (In reply to comment #342)
> > Tested the patch on v1.1.12 and the invisible issues is fixed. 
> > 
> 
> I meant the invisible chat issue is fixed ;)
> 

Tested also on 1.1.14 with success. Didn't see any problem related to this bug.

(In reply to comment #341)
> (In reply to comment #340)
> > yes, i finally got the patch to apply and to install the patched wine.  but
> > then when i launched war3 I got the error pop-up: audio does not work.  when I
> > launched winecfg the option for ALSA was removed and all I could pick was OSS,
> > and that didn't work either.
> > 
> 
> Are you sure you compiled wine with ALSA support after applying the patch? Also
> try compiling without the patch. My guess is you have been using a binary
> distribution before this patch.
> 

I experience a similar problem. Whenever I run WC3 by itself through the patched wine the sound works perfectly using the OSS driver. The issue comes when I run WC3 and any other application that has some type of sound output (Such as Amarok, VLC, even using flash in firefox). If I run Wine first and then any other application, the application I try to run just hangs and there is no audio playback. If I do it the other way around - open up an application and then Wine (WC3) - the application continues to have playback but wine has no sound and WC3 says: "Unable to initialize base sound, sound is disabled."
When I configure wine's Audio settings, I can only get output from the ALSA driver while running other sound-utilizing applications, but the sound output from Wine is gargled and causes a slight lag in game... its very annoying overall.
I am using Wine 1.1.9.
I just recently switched to Ubuntu(8.10 Intrepid), this is really the first issue that I've had. Do you guys have any tips?

Your sound card does not support hardware mixing.  This is not a problem with Wine.  Either you need to buy a better sound card that supports hardware mixing or enable support in Wine for a sound server.

Several years ago I bought a Sound Blaster Audigy 2.  New, it was over $100 but I bet you can pick one up on ebay for $20 these days (they were end of lifed years ago but mine still works like a champ).

(In reply to comment #345)
> I experience a similar problem. Whenever I run WC3 by itself through the
> patched wine the sound works perfectly using the OSS driver. The issue comes
> when I run WC3 and any other application that has some type of sound output
> (Such as Amarok, VLC, even using flash in firefox). If I run Wine first and
> then any other application, the application I try to run just hangs and there
> is no audio playback. If I do it the other way around - open up an application
> and then Wine (WC3) - the application continues to have playback but wine has
> no sound and WC3 says: "Unable to initialize base sound, sound is disabled."
> When I configure wine's Audio settings, I can only get output from the ALSA
> driver while running other sound-utilizing applications, but the sound output
> from Wine is gargled and causes a slight lag in game... its very annoying
> overall.
> I am using Wine 1.1.9.
> I just recently switched to Ubuntu(8.10 Intrepid), this is really the first
> issue that I've had. Do you guys have any tips?
> 

Yes, read about what pulseaudio is, it's perfect setup, and use padsp with wine's OSS to have wine and other audio run at the same time.
IMPORTANT: Set audio to emulation (and tick driver emulation) in winecfg, or you could experience crashes. (With emulation sound just goes away for wc3, rest of system is kept safe, at least for me)

> Yes, read about what pulseaudio is, it's perfect setup, and use padsp with
> wine's OSS to have wine and other audio run at the same time.
> IMPORTANT: Set audio to emulation (and tick driver emulation) in winecfg, or
> you could experience crashes. (With emulation sound just goes away for wc3,
> rest of system is kept safe, at least for me)
> 

I followed your advice and found out other things.
There was a bug With wine and pulseaudio that was fixed in Wine ver. 1.1.10 and above.
I followed a tutorial that I found on-line (http://www.ltyer.com/wordpress/tutorial-hostingplaying-warcraft-3-online-in-ubuntuperfectly/comment-page-1#comment-68).
This tutorial installs Wine 1.1.9... So my guess is to uninstall the version of Wine that I have, 1.1.9, and install  the new version of wine (which i believe is 1.1.14) and patch with what was provided in:(In reply to comment #334)
> Created an attachment (id=18638) [details]
> AcceptEx patch for 1.1.12 (without autogenerated files)
>

Correct?

*** Bug 13252 has been marked as a duplicate of this bug. ***

Could I request an AcceptEx patch that correctly applies to 1.1.18?

(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

(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

Created attachment 20299 [details]
Hopefully updated for 1.1.18
Typo, won't build.

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 on attachment 20299 [details]
Hopefully updated for 1.1.18
Typo, won't build.

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.

Created attachment 20300 [details]
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.

*** Bug 17951 has been marked as a duplicate of this bug. ***

Created attachment 20349 [details]
Buildlog: AcceptEx Patch does not work for wine 1.1.8

(In reply to comment #355)
> Created an attachment (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.

(In reply to comment #357)
> Created an attachment (id=20349) [details]
> Buildlog: AcceptEx Patch does not work for wine 1.1.8
> 
> (In reply to comment #355)
> > Created an attachment (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.

(In reply to comment #358)
> (In reply to comment #357)
> > Created an attachment (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.

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.

(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??

Created attachment 20615 [details]
Error compiling AcceptEx patched 1.1.18 version

Created attachment 20616 [details]
Error compiling AcceptEx patched 1.1.18 version

Created attachment 20617 [details]
Error compiling AcceptEx patched 1.1.18 version

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 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.

I've solved my problem. It was just some ip ports that I had to open.

(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.

*** Bug 15794 has been marked as a duplicate of this bug. ***

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.

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?

(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.

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.

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).

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.

Could someone send me a tutorial, with full detailed explanation, that helps me play Warcraft using Garena?

Created attachment 22193 [details]
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.

Would anyone with WC3 mind testing the patches at http://osdir.com/ml/wine-devel/2009-07/msg00275.html ?

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?

Created attachment 22428 [details]
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.

Created attachment 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?

Created attachment 22621 [details]
Set as of 7/25/2009

(In reply to comment #381)
> Created an attachment (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.

Created attachment 22700 [details]
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)

Created attachment 22759 [details]
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

Created attachment 22978 [details]
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.

Created attachment 23096 [details]
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.

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 on attachment 23096 [details]
Set as of 8/15/2009

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-objects-td25180261.html
http://www.nabble.com/-PATCH-2-7--server%3A-change-accept_socket-to-take-a-sock-*-td25180169.html
http://www.nabble.com/-PATCH-3-7--server%3A-replace-reselect_async-by-async_event-td25180171.html
http://www.nabble.com/-PATCH-4-7--server%3A-add-accept_into_socket-and-register_accept_async--requests-td25180188.html
http://www.nabble.com/-PATCH-5-7--ntdll%3A-add-wine_server_clear_handle_fd-to-clear-a-cached--fd-td25180256.html
http://www.nabble.com/-PATCH-6-7--ws2_32%3A-implement-AcceptEx-td25180182.html
http://www.nabble.com/-PATCH-7-7--ws2_32%3A-implement-GetAcceptExSockaddrs-td25180161.html

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.

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.

(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

Created attachment 24488 [details]
set of patches to Implement AcceptEx (try 6)

These patches are written by Mike Kaplinskiy edited by me to compile with Wine 1.1.32. Date of patches is Aug 28, 2009. Before running ./configure you have to run ./tools/make_requests

Patches supposedly fix Battle.net problem with Warcraft III. PlayOnLinux does include this (and more) patches during Warcraft III installation, so you can try it yourself or use POL.

(In reply to comment #392)
> Created an attachment (id=24488) [details]
> Patches supposedly fix Battle.net problem with Warcraft III. PlayOnLinux does
> include this (and more) patches during Warcraft III installation, so you can
> try it yourself or use POL.
I there a working patch for wine-1.1.19-3373-g38faaff? ( that is the latest git from here git://repo.or.cz/wine/war­craft3.git )

I tried the attached patches but I get a few errors when patching and a few when compiling:

async.c: In function ‘async_event’:
async.c:106: warning: implicit declaration of function ‘fd_async_event’
gcc -m32 -c -I. -I. -I../include -I../include  -D__WINESRC__  -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith  -g -O2  -o atom.o atom.c
gcc -m32 -c -I. -I. -I../include -I../include  -D__WINESRC__  -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith  -g -O2  -o change.o change.c
change.c:204: error: ‘default_fd_async_event’ undeclared here (not in a function)

Should I be using 1.1.32 and just the patches from last attachment?

I patched 1.1.32 successfully but game crashes with FATAL ERROR Access Violation as soon as I choose login to bnet. Nice improvement though first time using ALSA.

Basically the same result like using the wine-war3 git.

I think there is something newer going on with latest Wine (1.1.31 and 1.1.32). Before, these patches were only required to host games on Bnet, but BNet itself was working fine if you played on the ladder. Now I cannot login to Bnet at all - crashes with a Fatal error - access violation.

Should we open another bug for this fatal crash?

Also, any chances to see this newer set of patch accepted upstream?

(In reply to comment #395)
> I think there is something newer going on with latest Wine (1.1.31 and 1.1.32).
> Before, these patches were only required to host games on Bnet, but BNet itself
> was working fine if you played on the ladder. Now I cannot login to Bnet at all
> - crashes with a Fatal error - access violation.
> 
> Should we open another bug for this fatal crash?

Please open a new bug for that one.

Created attachment 24757 [details]
set of patches to Implement AcceptEx (Nov 02, 2009)

These patches are written by Mike Kaplinskiy edited by me to compile with Wine
1.1.33. Date of patches is Nov 02, 2009. Before running ./configure you have to
run ./tools/make_requests

Patches supposedly fix Battle.net problem with Warcraft III. PlayOnLinux does
include this (and more) patches during Warcraft III installation, so you can
try it yourself or use POL.

(In reply to comment #397)
> Created an attachment (id=24757) [details]
> set of patches to Implement AcceptEx (Nov 02, 2009)
> 
> These patches are written by Mike Kaplinskiy edited by me to compile with Wine
> 1.1.33. Date of patches is Nov 02, 2009. Before running ./configure you have to
> run ./tools/make_requests

[08:46] <JaimeRave> Hi julliard, what happened with the Mike Kaplinskiy patch series, they appear as "not even look at yet". Their id are 54854 - 54862
[08:49] <@julliard> yeah, there were too many versions of the same patches
[08:54] <JaimeRave> julliard: So he needs to resend?
[08:55] <@julliard> no, it needs a different approach
[08:55] <JaimeRave> julliard: ok, thanks

Well, maybe he referred to the old patch - because I think Mike's approach was already different / better than the first attempt... so we have to make sure Alexandre understood what you talked about.

(In reply to comment #397)
> Created an attachment (id=24757) [details]
> set of patches to Implement AcceptEx (Nov 02, 2009)
> 
> These patches are written by Mike Kaplinskiy edited by me to compile with Wine
> 1.1.33. Date of patches is Nov 02, 2009. Before running ./configure you have to
> run ./tools/make_requests
> 
> Patches supposedly fix Battle.net problem with Warcraft III. PlayOnLinux does
> include this (and more) patches during Warcraft III installation, so you can
> try it yourself or use POL.

:-( Patchset doesn't apply for me on Wine 1.1.34.

Hunk #3 of patch 0005 fails on servers/file.h.

Created attachment 25168 [details]
Set of patches to Implement AcceptEx for Wine 1.1.34

Patches written by Mike Kaplinskiy (attachment #24757 [details]), updated for wine 1.1.34. I didn't check if they actually work with 1.1.34, so it should compile but may blow up. :p

From comment #397:
> Before running ./configure you have to run ./tools/make_requests
> 
> Patches supposedly fix Battle.net problem with Warcraft III. PlayOnLinux does
> include this (and more) patches during Warcraft III installation, so you can
> try it yourself or use POL.

i have try the patch for wine-1.1.34 and dont work.

i think miss a little change in mapper.c that cause a compile error, i think i fix it.

but when i finish i get a error in every wine programs.
err:reg:create_scsi_entry()...

i think the new server have something wrong...

today is late, maybe tomorrow i have some time to spend to make more test and commit more useful information ;-)

Jack

Created attachment 25176 [details]
Set as of 12-12-2009

Here's a working patchset (it's rebased to current git, so may not work for 1.1.34 directly)

(In reply to comment #403)
> Created an attachment (id=25176) [details]
> Set as of 12-12-2009
> 
> Here's a working patchset (it's rebased to current git, so may not work for
> 1.1.34 directly)

This one didn't compile against 1.1.35:
 * Applying wine-1.1.35-0001-server-add-alloc_sock-to-init-socket-objects.patch 
 * Applying wine-1.1.35-0002-server-change-accept_socket-to-take-a-sock.patch 
 * Applying wine-1.1.35-0003-server-move-is_removeable-to-fd_ops.patch ...
 * Applying wine-1.1.35-0004-server-don-t-allow-caching-disconnected-SOCK_STREAM-so.patch ...
 * Applying wine-1.1.35-0005-server-replace-reselect_async-by-async_event.patch 
 * Applying wine-1.1.35-0006-server-add-async_terminated-to-allow-server-side-reque.patch ...
 * Applying wine-1.1.35-0007-server-create-register_accept_async-to-queue-async-acc.patch ...
 * Applying wine-1.1.35-0008-ws2_32-implement-AcceptEx.patch ...
 * Applying wine-1.1.35-0009-ws2_32-implement-GetAcceptExSockaddrs.patch ...

.....

i686-pc-linux-gnu-gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DUSE_WS_PREFIX -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wtype-limits -Wpointer-arith  -O2 -pipe -march=core2  -o socket.o socket.c
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include  -D__WINESRC__   -foversion.res version.rc
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include  -D__WINESRC__   -fowldap32_Da.res wldap32_Da.rc
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include  -D__WINESRC__   -fowldap32_De.res wldap32_De.rc
../../tools/winegcc/winegcc  -B../../tools/winebuild --sysroot=../.. -shared ./wintrust.spec    asn.o crypt.o register.o softpub.o wintrust_main.o    version.res    -o wintrust.dll.so -lcryptui -limagehlp -lcrypt32 -luser32 -ladvapi32 -lkernel32 -lntdll -Wb,-dcryptui -Wb,-dimagehlp ../../libs/port/libwine_port.a  -Wl,-O1 
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include  -D__WINESRC__   -fowldap32_En.res wldap32_En.rc
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include  -D__WINESRC__   -fowldap32_Es.res wldap32_Es.rc
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include  -D__WINESRC__   -fowldap32_Fr.res wldap32_Fr.rc
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include  -D__WINESRC__   -fowldap32_Ko.res wldap32_Ko.rc
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include  -D__WINESRC__   -fowldap32_Lt.res wldap32_Lt.rc
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include  -D__WINESRC__   -fowldap32_Nl.res wldap32_Nl.rc
../../tools/winegcc/winegcc  -B../../tools/winebuild --sysroot=../.. -shared ./wintrust.spec    asn.o crypt.o register.o softpub.o wintrust_main.o    version.res    -o wintrust.dll.fake -lcryptui -limagehlp -lcrypt32 -luser32 -ladvapi32 -lkernel32 -lntdll -Wb,-dcryptui -Wb,-dimagehlp ../../libs/port/libwine_port.a  -Wl,-O1 
socket.c: In function ‘AcceptEx’:
socket.c:5210: error: ‘union generic_request’ has no member named ‘register_accept_async_request’
socket.c:5210: error: ‘union generic_reply’ has no member named ‘register_accept_async_reply’
socket.c:5210: error: ‘REQ_register_accept_async’ undeclared (first use in this function)
socket.c:5210: error: (Each undeclared identifier is reported only once
socket.c:5210: error: for each function it appears in.)
socket.c:5212: error: dereferencing pointer to incomplete type
socket.c:5213: error: dereferencing pointer to incomplete type
socket.c:5214: error: dereferencing pointer to incomplete type
socket.c:5215: error: dereferencing pointer to incomplete type
socket.c:5216: error: dereferencing pointer to incomplete type
socket.c:5217: error: dereferencing pointer to incomplete type
make[2]: *** [socket.o] Error 1
make[2]: Leaving directory `/var/tmp/portage/app-emulation/wine-1.1.35/work/wine-1.1.35/dlls/ws2_32'
make[1]: *** [ws2_32] Error 2

You didn't run tools/make_requests.

Or even search this page for the same error: Comment #391 had this exact same issue two months ago, and was told to do that in the very next reply.

Created attachment 25410 [details]
log for WINEDEBUG=+sync,+winsock,+file wine SetupReg.exe

(In reply to comment #405)
> You didn't run tools/make_requests.
> 
> Or even search this page for the same error: Comment #391 had this exact same
> issue two months ago, and was told to do that in the very next reply.

I'm sorry, you are right. 

After installation of 1.1.35 with patches I have this error:
wine SetupReg.exe #program for setting up Warcraft 3 registry keys
wine: Invalid handle

I've used clean .wine directory. The same error appears, when I try to start Warcraft 3 (wine euroloader.exe -opengl) in already existing and working (when not patched) .wine directory.


If I install wine 1.1.35 without patches, there is no error when running SetupReg.exe nor Warcraft 3.

Oleg

(In reply to comment #406)
> Created an attachment (id=25410) [details]
> log for WINEDEBUG=+sync,+winsock,+file wine SetupReg.exe
> 
> (In reply to comment #405)
> > You didn't run tools/make_requests.
> > 
> > Or even search this page for the same error: Comment #391 had this exact same
> > issue two months ago, and was told to do that in the very next reply.
> 
> I'm sorry, you are right. 
> 
> After installation of 1.1.35 with patches I have this error:
> wine SetupReg.exe #program for setting up Warcraft 3 registry keys
> wine: Invalid handle
> 
> I've used clean .wine directory. The same error appears, when I try to start
> Warcraft 3 (wine euroloader.exe -opengl) in already existing and working (when
> not patched) .wine directory.
> 
> 
> If I install wine 1.1.35 without patches, there is no error when running
> SetupReg.exe nor Warcraft 3.
> 
> Oleg

I'm experiencing the same issue here.

After installation of 1.1.35 with patches I have this errors:
winecfg can`t connect with mount manager, in ~/.wine/drive_c i see only empty windows forlder, so this patches break wine at all

ArchLinux has a patched wine called wine-wc in the user repos.
It is version 1.1.35-5 and it works.
I didn't look exactly at the patches they use but you might want to have a look:
http://aur.archlinux.org/packages.php?ID=27298

The build process itself (defined in the build () function in the PKGBUILD file) seems to be standard.
But the 4 patches there might be something to look into.

(In reply to comment #409)
> ArchLinux has a patched wine called wine-wc in the user repos.
> It is version 1.1.35-5 and it works.
> I didn't look exactly at the patches they use but you might want to have a
> look:
> http://aur.archlinux.org/packages.php?ID=27298
> 
> The build process itself (defined in the build () function in the PKGBUILD
> file) seems to be standard.
> But the 4 patches there might be something to look into.

Wine-WC uses the patch to disable IO port completion. The patch is here on the page for this bug ( http://bugs.winehq.org/show_bug.cgi#attach_8368 )

Created attachment 25502 [details]
Set as of 01-02-2010

That should fix the problem. Seems I've missed a new fd that was added.

For the future, a message like that (Invalid Handle) means there was a new fd type added and you need to fix 3 of the patches in order to make it work again. In particular, patches 3, 5 and 6 are what you want to look at.

The command
grep -R -A 12 'const struct fd_ops [a-zA-Z]' server/*.c | less
might help to find which fd broke it (you will see a pattern broken).

I probably won't be rebasing these too often, so if it breaks again those are the instructions on how to fix it in one case.

i can play games but i randomly disconnect while being invited to join a game and warcraft shuts down. I can't host, the rest goes quite fine

*** Bug 22526 has been marked as a duplicate of this bug. ***

Hi all,

Applaying recomended patches has no effects for MetaTrader 5
Networking stays nonfunctional with diagnosis:

fixme:winsock:WSAIoctl SIO_GET_EXTENSION_FUNCTION_POINTER {25a207b9-ddf3-4660-8ee9-76e58c74063e}: stub
...

I tried to do a new patch based on Mike Kaplinskiy's ones from 01-02-2010, but I have problems with sock_try_event because it's not in server/sock.c anymore.

This is how far I got: http://pastebin.com/U3XBhFQK

What could I use instead? Is there a new patch/implementation in progress?

(In reply to comment #415)
> I tried to do a new patch based on Mike Kaplinskiy's ones from 01-02-2010, but
> I have problems with sock_try_event because it's not in server/sock.c anymore.
> 
> This is how far I got: http://pastebin.com/U3XBhFQK
> 
> What could I use instead? Is there a new patch/implementation in progress?

You can download new versions of Mike's patches from the wine-hacks git repository. It's kind of a pain to make sure you have them all, but I've been periodically downloading his patches from the git website for my Ubuntu packages, and they usually work fine on the current release.

http://repo.or.cz/w/wine/hacks.git/search/HEAD?s=Mike+Kaplinskiy;st=author

Thanks!

The patches didn't apply cleanly, but the patched files in wine-hacks gitweb helped a lot :-)

I was able to create patches working with current git head:
http://gitorious.org/flokli-overlay/flokli-overlay/trees/master/app-emulation/wine/files/9787_AcceptEx

@Mike K:
You still trying to get the patches accepted?
James

Not very actively, mostly because we are in code freeze. Implementing some of these (SIO_GET_EXTENSION_FUNCTION_POINTER) and not others may make some applications misbehave.

I will submit a partially working set for acceptex right after the release. It probably will work well since a lot of apps depend on the "closing accepting handle cancels request" behavior, but it will be a start. To implement that part of AcceptEx we need to restructure server async handling (i.e. 1 async waiting on multiple fd's). I have some patches written but they're not quite clean yet.

Won't happen for 1.2.

@Mike K:
First, thanks for your work!
Do you have any plans for 1.3? I would love to see a regular wine release where battle.net works again.

(In reply to comment #421)
> @Mike K:
> First, thanks for your work!
> Do you have any plans for 1.3? I would love to see a regular wine release where
> battle.net works again.

Patches have been resent.

Hopefully finally fixed by http://source.winehq.org/git/wine.git/?a=commitdiff;h=cf72f406ec7cdfebbd5135ede6e45547ca82dae0
?

I'm not going to close it though, I'll wait for some test results.

Either way, great work Mike!

war3 battle.net works for me with 1.3.4

(In reply to comment #424)
> war3 battle.net works for me with 1.3.4

Haha, you nearly got me!


Wait... this can't be true, how long did this bug exist? A decade?

For me eurobattle.net was working already with previous versions too ...

So, hopefully this patch did not broke functionality and it is still working.

Confirming as ( hopefully ) working now.

Reported fixed. For other or remaining issues open a new bug.


> morgan:
> Wait... this can't be true, how long did this bug exist? A decade?

I know. You forgot to send a patch nine years ago... What a mistake! :)

Closing bugs fixed in 1.3.5.