Guy,
> On Sun, Apr 18, 2004 at 02:43:05PM -0500, Alan S. Jones wrote: > > My impression from reading the WinPcap list was that programs should not > > need to make any changes to work between WinPcap 3.0 and 3.1. > > Applications using the raw packet-dll API *do* have to change: > > http://winpcap.polito.it/misc/changelog.htm > > "PacketGetAdapterNames() now returns the names of the adapter in ASCII > rather than in Unicode. Since the main purpose of > PacketGetAdapterNames() is feeding data to pcap_findalldevs() and since > pcap_findalldevs() needs ASCII names, the new PacketGetAdapterNames() > avoids a conversion in wpcap.dll and uniforms the data format with the > one of Windows 9x (this potentially simplifies the code of the > applications). As a consequence of this modification, old applications > won't work properly with the new PacketGetAdapteNames() on > NT/2k/XP/2k3." > > That difference probably was directly exposed by "pcap_lookupdev()", so > that it returned names in ASCII as well. >From tcpdump.org CVS, file inet.c: Revision : 1.57 Date : 2003/9/22 11:51:37 Author : 'risso' State : 'Exp' Lines : +61 -33 Description : pcap_lookupdev() converts the adapter list to unicode for backward compatibility. In other words, wpcap.dll is completely compatible with the past. I (and Gianluca) took maximum care about this. Loris > > Is this a bug in WinPcap? > > I'm not sure I'd call it one. It'd depend on how the WinPcap developers > said you *should* enumerate devices; if they recommended doing it, for > example, the way Ethereal does - it fetches the names with > "pcap_lookupdev()", and checks whether the first 2 bytes of the returned > string, treated as a 16-bit Unicode character, is < 256 or not, and: > > if it is, the strings are assumed to be Unicode strings; > > if it isn't, the strings are assumed to be ASCII strings > > and did *not* recommend assuming that on Windows OT (95, 98, Me) they're > ASCII and on Windows NT (NT 4.0, W2K, WXP, W2K3) they're Unicode, then > it's probably not a bug, as Ethereal-style code should continue to work > with 3.1. > > However, note that Ethereal also does something else: > > if libpcap/WinPcap has "pcap_findalldevs()", it uses that rather > than SIOCGIFLIST on UN*X or "pcap_lookupdev()" on Windows; > > and I'd recommend that other applications do so as well. (Yes, Ethereal > *does* make that determination at run time on Windows - it does a > "g_module_open()" on "wpcap" (which calls "LoadLibrary()" on > "wpcap.dll") and: > > if that fails, doesn't support packet capture; > > if that succeeds, looks up various symbols in WinPcap and calls > the relevant routines through the pointers it gets, if they're > > present. That was originally done so we could build one version of > Ethereal rather than a with-WinPcap and a without-WinPcap version, so it > adapts to whatever you have installed, but it also means we can use APIs > present in some but not all versions of WinPcap, if present, and not use > them if not present. I think that's a fairly common technique in > Windowsland; I used it on Linux in Ethereal for a while, thanks to some > annoying SNMP library problems.) > > > ================================================================== > This is the WinPcap users list. It is archived at > http://www.mail-archive.com/[EMAIL PROTECTED]/ > > To unsubscribe use > mailto: [EMAIL PROTECTED] > ================================================================== ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe use mailto: [EMAIL PROTECTED] ==================================================================
