On Tue, 1 Jun 2010 20:06:08 +0100 Bruce Cran <br...@cran.org.uk> wrote:
> I have a Winsock provider DLL which communicates with a kernel SCTP > stack. I'd like to enable applications built with both Visual Studio > and Cygwin to run because there's lots of code that's been ported from > Linux. However, the problem I've come across is that because I have a > few custom socket functions such as sctp_sendmsg and sctp_recvmsg that > don't go through the Winsock layer but still get a SOCKET > descriptor, I get passed Cygwin's internal file descriptor - i.e. I > can see my WSPAccept function returns a value of 161 up the stack but > it gets translated to 4 by Cygwin's socket code, and the 161 value > will be stored in the io_handle member of the fhandler_socket class. > I thought I could maybe use GetFileType and _get_osfhandle to deal > with running under Cygwin but it turns out that GetFileType tells me > I have a valid handle, and converting it using _get_osfhandle anyway > gives me an invalid handle back. > > Is there some way to detect that the handle's wrong and fetch the > proper one without my code needing detailed knowledge of the > fhandler_socket class? > I think I can see what the problem is now: since I call _get_osfhandle from within the Winsock provider, it seems to be bypassing the Cygwin layer; likewise, if I call getsockopt cygwin1.dll doesn't show up in the call stack either, and WSAENOTSOCK gets returned. The workaround I've come up with is to redefine my custom sctp_recvmsg function as being inline so it gets called within the context of the application; that means I can call getsockopt using a custom 'optname' which can return the SOCKET handle, having gone through cygwin1.dll. This seems to work, but is such a hack that I'm hoping there's some better solution. -- Bruce Cran -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
