[Bug 9787] Warcraft3 Battle.net Doesn't work (Needs AcceptEx)

http://bugs.winehq.org/show_bug.cgi?id=9787

Scott Lindeneau  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Raul  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

Jon  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #206 from Scott Lindeneau   2008-06-21 09:07:50 ---
I have been reviewing the patch that Andrey Turkin submitted 2008-01-08 and
would like to throw my 2 cents in. I haven't programmed in wine before, but I
wouldn't mind starting. Please tell me how/if/why I am wrong.

1) AcceptEx can return synchronously, but it doesn't matter if it does or not.
   * This means that for simplicity it shouldn't.

2) The AcceptEx call has all of the information it needs when its called.
   * All of the variables passed to AcceptEx must be initialized before it is
called.
   * The AcceptEx function itself should only be a wrapper for a wine server
call to start an async accept, and then it should return.

3) Essentially AcceptEx is an easy way to ask the Operating System to start a
thread to listen on a socket, and to get rid of the thread automatically.
   * We ask the wine server for an async accept (which should just be spawn a
thread, listen, and return after connect)

4) AcceptEx only adds the ability to read data on the socket before the
socket's error status changes from IO_PENDING to whatever.
   * Why not add this functionality into the wine server's async accept?

--- Comment #207 from Raul   2008-06-24 13:32:33 ---
acceptex unnofficial patch in deb package please!

--- Comment #208 from Austin English   2008-06-24 16:11:23 ---
(In reply to comment #207)
> acceptex unnofficial patch in deb package please!

Ask the maintainer to do that. Hacks are not accepted in WineHQ's codebase.

You could compile it yourself...

--- Comment #209 from Raul   2008-06-24 17:55:56 ---
after a long time downloading and compiling....

the "Disable completion port creation" patch didn't work...

I just have to get in my git dir and do
"patch -Np1 < mypatch.diff && tools/make_requests"???

--- Comment #210 from Scott Lindeneau   2008-06-29 02:53:29 ---
(In reply to comment #209)
> after a long time downloading and compiling....
>
> the "Disable completion port creation" patch didn't work...
>
> I just have to get in my git dir and do
> "patch -Np1 < mypatch.diff && tools/make_requests"???

then you have to
> make depend
> make
> sudo make uninstall
> sudo make install

and type your password if prompted for the sudo.

--- Comment #211 from Jon   2008-06-29 02:57:29 ---
(In reply to comment #0)
> Today's patches have caused Warcraft 3 battle.net to stop working. When
> connecting to Battle.net the "Connecting to Battle.net" box just idles
> indefinitely. No terminal output.
>
> I haven't run a regression yet so I don't know exactly which patch causes this.

I had this issue with wine 1.0 and the RC's. My work around was to click
battle.net then cancel (as it would get stuck) then click battle.net again, it
will work instantly the 2nd time.

--- Comment #212 from Peter   2008-06-29 04:21:49 ---
(In reply to comment #211)
> (In reply to comment #0)
> > Today's patches have caused Warcraft 3 battle.net to stop working. When
> > connecting to Battle.net the "Connecting to Battle.net" box just idles
> > indefinitely. No terminal output.
> >
> > I haven't run a regression yet so I don't know exactly which patch causes this.
>
> I had this issue with wine 1.0 and the RC's. My work around was to click
> battle.net then cancel (as it would get stuck) then click battle.net again, it
> will work instantly the 2nd time.

I have the same problem, clicking cancel helps, but this regression is in Wine
probably since 0.9.50 (I don't know exact Wine version).

(In reply to comment #210)
> (In reply to comment #209)
> > after a long time downloading and compiling....
> >
> > the "Disable completion port creation" patch didn't work...
> >
> > I just have to get in my git dir and do
> > "patch -Np1 < mypatch.diff && tools/make_requests"???
>
> then you have to
> > make depend
> > make
> > sudo make uninstall
> > sudo make install
>
> and type your password if prompted for the sudo.

I'd try "sudo checkinstall" instead of sudo make install and sudo make
uninstall, because checkinstall creates package, that does NOT harm you package
system as "make" do.

--- Comment #213 from Andrey Turkin   2008-06-29 06:19:29 ---
(In reply to comment #206)
> I have been reviewing the patch that Andrey Turkin submitted 2008-01-08 and
> would like to throw my 2 cents in. I haven't programmed in wine before, but I
> wouldn't mind starting. Please tell me how/if/why I am wrong.
> - 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.
> - 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.
> - 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.
> - 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.