jscott wrote:
I have what's probably a sub-set of the ethereal code that's used to build a
Windows static link library. It was created by ClearSight, another sniffer
company and distributed as a demo of how to use the ethereal dissectors in
another app. What I'm trying to do is use that library in our (Wildpackets)
decode test app. We compile everything as Unicode, so I need to get a build
of the ethereal library as Unicode. ClearSight used the multibyte char set
build, which isn't exactly the same as Unicode. When compiling ethereal as
Unicode, the only file that gave errors was filesystem.c.
What errors did it give? And, if all the code in your app that uses it
passes Unicode path name strings to the routines, have you changed
filesystem.c to handle Unicode strings rather than byte strings?
(BTW, if that app is *only* used internally to WildPackets, there are no
GPL issues, at least as far as I know - but it might be nice if, in
exchange, WildPackets contributes any useful improvements that could be
made to the code to read {Ether,Token,Airo}Peek files; see both
wiretap/etherpeek.c and wiretap/airopeek9.c. Those might include:
support for older versions of the file format;
handling of or, at least, description of what some of the unknown
fields in the headers are;
information on how to tell whether a frame includes an FCS or not;
information on what the 4 bytes at the end of packets in
pre-version-9-file-format AiroPeek files is;
information on what some of the unidentified tagged fields in
version-9-file-format captures are (e.g., a tag of 13/0x000D).
Given that you also have ProConvert, improvements to any code to read
other capture file formats might be nice as well. Note that all such
improvements would have to be licensed under the GPL.)
