9 Sep
2015
9 Sep
'15
4:31 a.m.
Hi all, a possible way to solve the WSACleanup in the DLL side is to
retrieve all existing sockets from the current process in a server
call and then closing then inside winsock. Is it possible to make a
wine server call that returns variable length data? If yes, can anyone
show an example?
Such function would also allow for a proper implementation of
SetTcpEntry (iphlpapi) which would make firewalls that like to close
TCP connections happy.
9 Sep
9 Sep
1:47 p.m.
On 9 September 2015 at 06:31, Bruno Jesus <00cpxxx(a)gmail.com> wrote:
Hi all, a possible way to solve the WSACleanup in the
DLL side is to
retrieve all existing sockets from the current process in a server
call and then closing then inside winsock. Is it possible to make a
wine server call that returns variable length data? If yes, can anyone
show an example?
Yes, see the various requests with VARARG() replies. In ws2_32 in
particular there's _get_sock_errors(), although that uses a fixed
buffer. In ntdll there's e.g. server_get_unix_name().
9:17 p.m.
Why are we looking at the dll side again?
-Matt
On Sep 9, 2015, at 9:47 AM, Henri Verbeet
<hverbeet(a)gmail.com> wrote:
On 9 September 2015 at 06:31, Bruno Jesus <00cpxxx(a)gmail.com> wrote:
Hi all, a possible way to solve the WSACleanup in
the DLL side is to
retrieve all existing sockets from the current process in a server
call and then closing then inside winsock. Is it possible to make a
wine server call that returns variable length data? If yes, can anyone
show an example?
Yes, see the various requests with VARARG() replies. In ws2_32 in
particular there's _get_sock_errors(), although that uses a fixed
buffer. In ntdll there's e.g. server_get_unix_name().
10 Sep
10 Sep
12:04 a.m.
On Wednesday, September 9, 2015, Matt Durgavich <mattdurgavich(a)gmail.com>
wrote:
Why are we looking at the dll side again?
Closing the sockets server side does not clear the ntdll cache, the current
solution is incomplete then as functions like send and closesocket will
fail for the wrong reasons because the socket is still "available".
Best regards,
Bruno
6:06 p.m.
That’s unfortunate. Where is the caching taking place?
On Sep 9, 2015, at 8:04 PM, Bruno Jesus
<00cpxxx(a)gmail.com> wrote:
On Wednesday, September 9, 2015, Matt Durgavich <mattdurgavich(a)gmail.com
<mailto:[email protected]>> wrote:
Why are we looking at the dll side again?
Closing the sockets server side does not clear the ntdll cache, the current solution is
incomplete then as functions like send and closesocket will fail for the wrong reasons
because the socket is still "available".
Best regards,
Bruno
11 Sep
11 Sep
2:43 a.m.
On Thursday, September 10, 2015, Matt Durgavich <mattdurgavich(a)gmail.com>
wrote:
That’s unfortunate. Where is the caching taking
place?
Inside ntdll, from inside ws2_32 follow the get_sock_fd call an you will
reach ntdll, I'm replying from mobile phone so I can't give source details.
On Sep 9, 2015, at 8:04 PM, Bruno Jesus <00cpxxx(a)gmail.com
<javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
On Wednesday, September 9, 2015, Matt Durgavich <mattdurgavich(a)gmail.com
<javascript:_e(%7B%7D,'cvml','[email protected]');>>
wrote:
Why are we looking at the dll side again?
Closing the sockets server side does not clear the ntdll cache, the
current solution is incomplete then as functions like send and closesocket
will fail for the wrong reasons because the socket is still "available".
Best regards,
Bruno
24 Nov
24 Nov
6:07 p.m.
After some time struggling with the server I finally managed to
produce a working version of the idea of bringing all sockets from
server to winsock and then closing all of them. Tested with 1026
sockets and seems to work as expected by bringing 128 sockets per
request from the server.
This is certainly too much for code freeze but I plan to send after
it, feedback is very much welcome since mistakes are always possible
when working after midnight.
Best wishes,
Bruno
6:20 p.m.
On 24.11.2015 19:07, Bruno Jesus wrote:
After some time struggling with the server I finally
managed to
produce a working version of the idea of bringing all sockets from
server to winsock and then closing all of them. Tested with 1026
sockets and seems to work as expected by bringing 128 sockets per
request from the server.
This is certainly too much for code freeze but I plan to send after
it, feedback is very much welcome since mistakes are always possible
when working after midnight.
Best wishes,
Bruno
I'm not sure, but probably the following, slightly modified idea would
be preferred. On Windows there is also a way to enumerate all handles:
SystemHandleInformation. I have already started writing patches for this:
https://github.com/wine-compholio/wine-staging/tree/master/patches/ntdll-Sy…
If tests confirm that WSACleanup really closes all sockets, including
those created with DuplicateHandle(), then we could use this ntdll API
to enumerate them. Even if we decide not to use the ntdll API, we could
at least use one shared wineserver call for both.
Nevertheless, similar to your approach, I do not see any chance to get
this upstream now during the feature freeze. Applications might start
using it, and then fail if something doesn't work as expected - so its
better to wait. ;)
Regards,
Sebastian
25 Nov
25 Nov
1:52 a.m.
On Wed, Nov 25, 2015 at 2:20 AM, Sebastian Lackner
<sebastian(a)fds-team.de> wrote:
I'm not sure, but probably the following, slightly
modified idea would
be preferred. On Windows there is also a way to enumerate all handles:
SystemHandleInformation. I have already started writing patches for this:
https://github.com/wine-compholio/wine-staging/tree/master/patches/ntdll-Sy…
Outstanding! If I can simply use this function instead of messing with
wineserver it will be very good. I tried looking for some use examples
of this functions but they seem rare.
If tests confirm that WSACleanup really closes all
sockets, including
those created with DuplicateHandle(), then we could use this ntdll API
to enumerate them. Even if we decide not to use the ntdll API, we could
at least use one shared wineserver call for both.
I'll write some more winsock tests related to this.
Best regards,
Bruno
3078
days inactive
3155
days old
8 comments
4 participants
participants (4)
-
Bruno Jesus -
Henri Verbeet -
Matt Durgavich -
Sebastian Lackner