I started working on the "Fileshark" concept [1]. As part of the architecture, I don't believe "Fileshark" should include the dissector.lib as noted in the original discussion [2], but should include the rest of the epan directory ($LIBWIRESHARK_OBJECTS). I hacked the nmake configuration in an attempt to make that happen and came across a handful of link errors. Below is a description and what I think should be done about them (??? means either I don't know or don't really like my provided solution). Any additional suggestions (including completely different approaches) are welcome .
mtp3_pc_to_str_buf() - ??? The problem is that the format is determined by a preference in the mtp3 dissector, otherwise I would think address_to_str.c would be a fine place for the function.
radius_dict.c - missing "basic type handling" functions from packet-radius.c. ??? Since radius_dict.c is autogenerated, make an accompanying radius_(something).c in epan directory to include the "basic type handling" functions
tcap-persistentdata.c - lists and hash tables used for tcap dissector. Should really be in packet-tcap[-template].c
camel-persistentdata.c - same as tcap
print.c - hf_ fields from from frame and data dissectors in order to output data values. ???
gcp.[ch] - Context tracking for Gateway Control Protocol. Used by a few dissectors - just put the functionality in one of them.
follow.c - get_tcp_conversation_data() - move in from packet-tcp.c (some other related functionality needs to be pulled in too)
exported_pdu.c - dvbci_get_evt_from_addrs - ??? part of "address handling" of epan? to_str?
One other solution I thought of was to create a separate "grouping" in the build configuration that wouldn't have "very dissector specific files" in the epan directory, but I wanted to avoid that duplication (or a confusing meaning of "common") if possible. Maybe expand wsutils?
