On Apr 22, 2013, at 6:51 AM, Gisle Vanem <[email protected]> wrote:
> Anyway, when you call 'pcap_fopen_offline()' in the DLL (with it's own > independent C-runtime lib), it expects the 'FILE *fp' argument to be relative > to this CRT. But it's not apparently not. You give winpcap.dll a 'fp' that is > relative to *your* C-runtime library. I.e. you're mixing data between > boundaries. This is a big no-no on Windows. I.e., a FILE structure created by one version of the C runtime library could be different from a FILE structure created by another version, so if an fopen() is done in code using one version of the library, the FILE * it returns can't necessarily be used by code using another version. In particular, a FILE * from an fopen() done in a program linked with WinPcap can't be used by any of the packet-reading routines in WinPcap, and a FILE * from an fopen() or fdopen() done in WinPcap can't be used by calls such as fseek() in a program using WinPcap. This means that, in order to write code that does random access to pcap files, and have that code portable between UN*X and Windows, the APIs doing the seeks would have to be part of libpcap/WinPcap, and the code would have to use that. Note also that libpcap 1.1.0 and later can also read pcap-ng files, so even on UN*X you'd have to be very careful not to make any assumptions about the underlying structure of the file, so that's arguably another reason to have the seek and tell functions in libpcap/WinPcap. _______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
