guy at alum.mit.edu
Sat Aug 6 17:32:10 GMT 2005
Loris Degioanni wrote:
> However, we always told our users that they sould consider packet.dll an
> *internal* API: we want the freedom to change it, if needed, to support
> the underlying layers in the best possible way.
Or, to put it another way, the packet.dll API in version X of WinPcap
might be a clearer API, and the packet.dll API in version Y of WinPcap
might be a clearer API, but there is *NO* guarantee that they'll be the
I.e., if you write a program that uses the packet.dll API from version X
of WinPcap, that program might fail to start on a system with version Y
of WinPcap installed (if, for example, it calls a routine that's in
packet.dll in version X but not in packet.dll in version Y), or it might
crash (if a routine it calls has more arguments in version Y than in
version X, so whatever garbage was on the stack in the call is
interpreted as the argument, or if the routine interprets its arguments
differently in version Y than in version X).
So if you like the packet.dll API more than the libpcap/WinPcap API, OK,
but bear in mind that you might have to modify your program when a new
version of WinPcap comes out (and that the developers of WinPcap might
not freeze the packet.dll API even if people say they want it to become
a stable API).
> wpcap.dll, on the other
> side, is guaranteed to be stable (unless libpcap changes).
...and libpcap's API isn't going to change in a way that's not
backwards-compatible (other than bug fixes - we're not necessarily going
to provide "bug-for-bug compatibility").
More information about the Winpcap-users