http://bugs.winehq.org/show_bug.cgi?id=16047
--- Comment #21 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2010-07-16 14:25:03 --- (In reply to comment #20)
Thanks for the pointer.
However I'm not familiar with the ws2 apis and and not sure how they work. Did you mean the wine implementation of WSASendTo and WSARecvFrom are done asynchronously, which might be causing problem?
Also, did you mean having one helper function that handles both WSASendTo and WSARecvFrom?
Thanks again.
You don't need to be familiar with the API's, just C. You should create (just rename works) two helpers (one for each) for WSASendTo and WSARecvFrom. Then replace all calls to WSASendTo/WSARecvFrom within ws2_32 to call the helpers instead (you can do 90% of that with find/replace). Don't forget to rewrite the actual WSARecvFrom/WSASendTo and have them call the helper as well.
The problem is that Warcraft uses different socket layers in different places. In some places it might call send/WSASend and recv/WSARecv whereas in others it uses WSASendTo and WSARecvFrom. Garena looks to hook only WSASendTo/WSARecvFrom. This is because it probably only wants to intercept packets for connecting to a game and not whatever else Warcraft does.
Wine implements send/WSASend and recv/WSARecv by calling WSASendTo/WSARecvFrom which ends up going to Garena code and confusing Garena since it only expects calls from Warcraft. So if we stop calling WSASendTo/WSARecvFrom from within wine code (by calling the helper instead) Garena won't receive any calls and should be happy. I don't know if it will fix all the problems, but I think that's what is happening.
I'd write the patch for you, but I'm not around a git tree. See if you can do it yourself with a bit of help from #winehq