[Winpcap-users] packet.dll

[Guy Harris]

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 
*same* API....

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").