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.
On 9 September 2015 at 06:31, Bruno Jesus 00cpxxx@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().
Why are we looking at the dll side again?
-Matt
On Sep 9, 2015, at 9:47 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 9 September 2015 at 06:31, Bruno Jesus 00cpxxx@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().
On Wednesday, September 9, 2015, Matt Durgavich mattdurgavich@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
That’s unfortunate. Where is the caching taking place?
On Sep 9, 2015, at 8:04 PM, Bruno Jesus 00cpxxx@gmail.com wrote:
On Wednesday, September 9, 2015, Matt Durgavich <mattdurgavich@gmail.com mailto:mattdurgavich@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
On Thursday, September 10, 2015, Matt Durgavich mattdurgavich@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@gmail.com javascript:_e(%7B%7D,'cvml','00cpxxx@gmail.com');> wrote:
On Wednesday, September 9, 2015, Matt Durgavich <mattdurgavich@gmail.com javascript:_e(%7B%7D,'cvml','mattdurgavich@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
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
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-Sys...
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
On Wed, Nov 25, 2015 at 2:20 AM, Sebastian Lackner sebastian@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-Sys...
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
-
Bruno Jesus -
Henri Verbeet -
Matt Durgavich -
Sebastian Lackner