[Winpcap-users] pcap_fopen_offline not exported?
guy at alum.mit.edu
Fri Jul 25 22:59:41 GMT 2008
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:
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
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:
seems to indicate that
1) you can get socket handles (although whether they're HANDLEs is
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:
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
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
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
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
although they're not UN*Xy enough to allow what appears to be the
equivalent of dup()/dup2() to work....)
More information about the Winpcap-users