[Winpcap-users] pcap_fopen_offline not exported?

[Guy Harris]

On Jul 25, 2008, at 3:27 PM, Gianluca Varenni wrote:

> this could work as long as you can get a FILE* handle out of a win32  
> HANDLE. I've never tried myself, it looks a bit scary to me...

I don't know whether you can do so in one step, but the  
_open_osfhandle() documentation seems to imply that you can get a C  
run-time library file descriptor give "an existing operating-system  
file handle" and the _fdopen() documentation indicates that you can  
get a FILE * from a C run-time library file descriptor.

The knowledgebase article Q99173:

	http://support.microsoft.com/kb/q99173/

also indicates that _open_osfhandle() can be used on a HANDLE,  
although it also indicates that you shouldn't use the HANDLE directly  
after that, as you might get it out of sync with the C run-time  
library FD:

	It is also possible to construct a C Run-time unbuffered file I/O  
handle from an operating system handle [a CreateFile() handle] with  
the _open_osfhandle() C Run-time API. In this case, the C Run-time  
uses the existing operating system handle that you pass in rather than  
opening the file itself. It is possible to use the original operating  
system handle to read or write to the file, but it is very important  
that you use only the original handle or the returned C Run-time  
handle to access the file, but not both, because the C Run-time  
maintains state information that will not be updated if you use the  
operating system handle to read or write to the file.

(BTW, KB article 139801:

	http://support.microsoft.com/kb/139801

seems to indicate that

	1) you can get socket handles (although whether they're HANDLEs is  
another matter)

and

	2) you can hand them to _open_osfhandle() on Windows NT (including,  
presumably, NT 5 and NT 6)

so that NT's sockets are UN*Xy enough that they can be used  
interchangeably with file descriptors to some degree (well, TCP  
sockets, at least, which are the ones where you are most likely to  
want to use a socket as if it were an FD).

The Winsock 2 programming documentation says the same thing:

	Socket Handles
	A socket handle can optionally be a file handle in Windows Sockets 2.  
A socket handle from a Winsock provider can be used with other non- 
Winsock functions such as ReadFile,WriteFile, ReadFileEx, and  
WriteFileEx.

	The XP1_IFS_HANDLES member in the protocol information structure for  
a provider determines whether a socket handle from a provider is an  
Installable File System (IFS) handle. Socket handles that are IFS  
handles can be used without a performance penalty with other non- 
Winsock functions (ReadFile and WriteFile, for example). Any non-IFS  
socket handles when used with non-Winsock functions (ReadFile and  
WriteFile, for example) result in interactions between the provider  
and the file system where extra processing overhead is involved that  
can result in a significant performance penalty. When using socket  
handles with non-Winsock functions, the error codes propagated from  
the base file system are not always mapped to Winsock error codes.  
Consequently, it is recommended that socket handles be used only with  
Winsock functions.

	A socket handle should not be used with the DuplicateHandle function.  
The presence of layered service providers (LSPs) can cause this to  
fail and there is no way for the destination process to import the  
socket handle.

	Windows Sockets 2 has expanded certain functions that transfer data  
between sockets using handles. The functions offer advantages specific  
to sockets for transferring data and include WSARecv, WSASend, and  
WSADuplicateSocket.

although they're not UN*Xy enough to allow what appears to be the  
equivalent of dup()/dup2() to work....)