On Mon, Sep 04, 2000 at 03:16:21PM +0200, Loris Degioanni wrote:
> We are thinking, from next release, to distribute libpcap as a dll.
> This, among other advantages, will allow the many non-VisualC
> programmers to use winpcap easily (we had many requests to support
> Delphi, VB, Cbuilder, etc.). Moreover, this will make applications
> independent from the upgrades of winpcap/libpcap.
> Do you think that this will have any drawbacks?
It would require that the binary interface to libpcap be kept stable, or
that programs built with different versions of libpcap be linked at
run-time with the appropriate version of libpcap - UNIX systems
typically would do this by changing the library major version number if
the interface changes in a way that breaks binary compatibility, but I
don't know what mechanisms there are to do that in Windows other than
"ensure that there's a libpcap.dll of the appropriate version in the
same directory as the program running it".
Other than that, I can't think of any such drawbacks (I'm assuming that
"libpcap.dll" will be installed, as part of the WinPcap installation
procedure, in the same directory as "packet.dll", so that whatever steps
need to be taken to ensure that "packet.dll" is found when a
libpcap-based application is run will also ensure that "libpcap.dll" is
found); it's already a dynamically-linked shared library in FreeBSD (and
probably other BSDs), and may also be one in some if not all Linux
distributions.