I ran into a bug last week regarding the lack of SIO_GET_EXTENSION_FUNCTION_POINTER support in WSAIoctl.
Are there any outstanding issues preventing it's implementation?
Perhaps if anyone has worked in this area, are there any things I should look out for when trying to implement it? At first glance it looks like returning an arbitrary pointer may prove tricky since wine likes to relocate DLLs to unpredictable addresses at runtime. (i.e. kernel32.dll is not predictably mapped to a single address as with Windows XP; turning off ASR for the current shell has no effect)
-Nick
On Mon, Sep 7, 2009 at 2:45 AM, Nicholas LaRochenlaroche@vt.edu wrote:
I ran into a bug last week regarding the lack of SIO_GET_EXTENSION_FUNCTION_POINTER support in WSAIoctl.
Are there any outstanding issues preventing it's implementation?
Perhaps if anyone has worked in this area, are there any things I should look out for when trying to implement it? At first glance it looks like returning an arbitrary pointer may prove tricky since wine likes to relocate DLLs to unpredictable addresses at runtime. (i.e. kernel32.dll is not predictably mapped to a single address as with Windows XP; turning off ASR for the current shell has no effect)
-Nick
There is nothing particularly hard about implementing it. SIO_GET_EXTENSION_FUNCTION_POINTER is microsoft's special "winsock extensions"; it is a way to call functions like AcceptEx, GetAcceptExSockaddrs, ConnectEx, DisconnectEx, and TransmitFile. Each of these functions has its own guid which you pass to wsaioctl to get a pointer to it (look at ws2_32 acceptex tests). It doesn't matter what the memory maps to, it's simply that they are not implemented.
For AcceptEx & GetAcceptExSockaddrs, there is a patch in the mailing list that implemented them, but Alexandre rejected the patch.
Mike.
Mike Kaplinskiy wrote:
On Mon, Sep 7, 2009 at 2:45 AM, Nicholas LaRochenlaroche@vt.edu wrote:
I ran into a bug last week regarding the lack of SIO_GET_EXTENSION_FUNCTION_POINTER support in WSAIoctl.
Are there any outstanding issues preventing it's implementation?
Perhaps if anyone has worked in this area, are there any things I should look out for when trying to implement it? At first glance it looks like returning an arbitrary pointer may prove tricky since wine likes to relocate DLLs to unpredictable addresses at runtime. (i.e. kernel32.dll is not predictably mapped to a single address as with Windows XP; turning off ASR for the current shell has no effect)
-Nick
There is nothing particularly hard about implementing it. SIO_GET_EXTENSION_FUNCTION_POINTER is microsoft's special "winsock extensions"; it is a way to call functions like AcceptEx, GetAcceptExSockaddrs, ConnectEx, DisconnectEx, and TransmitFile. Each of these functions has its own guid which you pass to wsaioctl to get a pointer to it (look at ws2_32 acceptex tests). It doesn't matter what the memory maps to, it's simply that they are not implemented.
For AcceptEx & GetAcceptExSockaddrs, there is a patch in the mailing list that implemented them, but Alexandre rejected the patch.
Mike.
Those patches are exactly what I was looking for. Thanks!
What revision did you test on?
-Nick
On Mon, Sep 7, 2009 at 11:08 AM, Nicholas LaRochenlaroche@vt.edu wrote:
Mike Kaplinskiy wrote:
On Mon, Sep 7, 2009 at 2:45 AM, Nicholas LaRochenlaroche@vt.edu wrote:
I ran into a bug last week regarding the lack of SIO_GET_EXTENSION_FUNCTION_POINTER support in WSAIoctl.
Are there any outstanding issues preventing it's implementation?
Perhaps if anyone has worked in this area, are there any things I should look out for when trying to implement it? At first glance it looks like returning an arbitrary pointer may prove tricky since wine likes to relocate DLLs to unpredictable addresses at runtime. (i.e. kernel32.dll is not predictably mapped to a single address as with Windows XP; turning off ASR for the current shell has no effect)
-Nick
There is nothing particularly hard about implementing it. SIO_GET_EXTENSION_FUNCTION_POINTER is microsoft's special "winsock extensions"; it is a way to call functions like AcceptEx, GetAcceptExSockaddrs, ConnectEx, DisconnectEx, and TransmitFile. Each of these functions has its own guid which you pass to wsaioctl to get a pointer to it (look at ws2_32 acceptex tests). It doesn't matter what the memory maps to, it's simply that they are not implemented.
For AcceptEx & GetAcceptExSockaddrs, there is a patch in the mailing list that implemented them, but Alexandre rejected the patch.
Mike.
Those patches are exactly what I was looking for. Thanks!
What revision did you test on?
-Nick
The last revision i had was try 6, and it should apply cleanly to master.
Mike.
Mike Kaplinskiy wrote:
On Mon, Sep 7, 2009 at 11:08 AM, Nicholas LaRochenlaroche@vt.edu wrote:
Mike Kaplinskiy wrote:
On Mon, Sep 7, 2009 at 2:45 AM, Nicholas LaRochenlaroche@vt.edu wrote:
I ran into a bug last week regarding the lack of SIO_GET_EXTENSION_FUNCTION_POINTER support in WSAIoctl.
Are there any outstanding issues preventing it's implementation?
Perhaps if anyone has worked in this area, are there any things I should look out for when trying to implement it? At first glance it looks like returning an arbitrary pointer may prove tricky since wine likes to relocate DLLs to unpredictable addresses at runtime. (i.e. kernel32.dll is not predictably mapped to a single address as with Windows XP; turning off ASR for the current shell has no effect)
-Nick
There is nothing particularly hard about implementing it. SIO_GET_EXTENSION_FUNCTION_POINTER is microsoft's special "winsock extensions"; it is a way to call functions like AcceptEx, GetAcceptExSockaddrs, ConnectEx, DisconnectEx, and TransmitFile. Each of these functions has its own guid which you pass to wsaioctl to get a pointer to it (look at ws2_32 acceptex tests). It doesn't matter what the memory maps to, it's simply that they are not implemented.
For AcceptEx & GetAcceptExSockaddrs, there is a patch in the mailing list that implemented them, but Alexandre rejected the patch.
Mike.
Those patches are exactly what I was looking for. Thanks!
What revision did you test on?
-Nick
The last revision i had was try 6, and it should apply cleanly to master.
Mike.
I had a few issues applying your patches to the latest git revision, but I did find equivalent functionality in wine-hacks. This solved my problem however the code in this tree doesn't support AcceptEx with TCP.
http://repo.or.cz/w/wine/hacks.git
-Nick
On Tue, Sep 8, 2009 at 12:03 PM, Nicholas LaRochenlaroche@vt.edu wrote:
I had a few issues applying your patches to the latest git revision, but I did find equivalent functionality in wine-hacks. This solved my problem however the code in this tree doesn't support AcceptEx with TCP.
http://repo.or.cz/w/wine/hacks.git
-Nick
I'm fairly certain it works with TCP as there is nothing protocol specific in the code. Also the wine tests for AcceptEx are TCP based and pass with the series. Try looking at the winsock log to see if there are any errors. I think we might want to take this off the list though, since it's a rejected patch.
Mike.
-
Mike Kaplinskiy -
Nicholas LaRoche