X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,BAYES_00,TW_CV,TW_SF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Wed, 2 Jun 2010 12:02:17 +0100 From: Bruce Cran To: Bruce Cran Cc: cygwin AT cygwin DOT com Subject: Re: Using custom Winsock socket functions with Cygwin Message-ID: <20100602120217.00000395@unknown> In-Reply-To: <20100601200608.00006958@unknown> References: <20100601200608 DOT 00006958 AT unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Tue, 1 Jun 2010 20:06:08 +0100 Bruce Cran 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