Although I applaud the approach in general, it only solves the issue from a build side. There are still a lot of things happening in the epan code that directly affect UI/UX behavior (columns, statistics, resolving of names, expert information (not translatable), ...) that will not be affected.
As much as I think it can help us be better in implementing epan, but what is the ultimate goal? To use the same library for both Stratoshark/Wireshark at runtime? To have it integrated in other projects? I am somewhat missing that context. On the general approach, kudos and I think worth from a purely build perspective cheers Roland Am Mi., 12. Nov. 2025 um 16:13 Uhr schrieb Michael Mann via Wireshark-dev < [email protected]>: > (subject line reference explained by [1]) > > For years I've wanted the epan directory to be a standalone library as a > "dissection engine". When Wireshark was ported to use Qt, that was an > opportunity to put a lot more "dissector engine business logic" in its > proper layer (epan) away from the UI. However, still some loose ends > remained (with linking issues if certain dissectors were removed). When > Stratoshark came along it seemed even more important to try to have a > cleaner separation of the engine from the UI. So, I started working on > cleaning things up so that epan could be its own library. > > My success can be seen with [2]. Applying that patch you can build and > run Wireshark without any dissectors. You'll get a few error message pop > ups from "missing dissectors", especially if you load a pcap file and the > color filters try to run, but Wireshark will display the correct number of > packets, with most columns not populated. (Yes, I submitted several MRs to > ensure Wireshark didn't crash without dissectors and just graciously > showed error messages.) > > What I want is feedback from the dev-list on where to go from here. Do > people like the idea? Should "epan.lib" be more formalized? (My CMake > skills aren't great, so I'd probably ask for volunteers in helping with > that formalization if there is desire) > > Also because of Stratoshark (and remembering the visions of FileShark > [3]), I've been trying to more formally create an "application layer" > library [4] (based off of wsutil/application_flavor.[c|h]) where the > "dissection engine" is more parameterized to (eventually) include things > like what dissectors get registered. This would make it possible for > someone to have a version of Wireshark with significantly less dissectors > than the standard distribution (or provide their library of dissectors for > in house development), almost as if all built-ins themselves were a single > (large) plugin. It could also lead to an application like Fileshark where > the dissection engine is used to parse files for view (and only dissectors > for files are built into the application). > > The one "gotcha" that I have already found is that if we do have epan.lib > as the "dissection engine library", that library should include the frame, > file, and data dissectors and those are the basis for dissecting any piece > of data. Seems easy enough to just move the code around to make that > happen (and not have those dissectors be part of the autogenerated list in > dissectors.c). > > What do you think? > > Michael > > > [1] https://www.mentalfloss.com/language/look-ma-no-hands-origin > [2] https://gitlab.com/wireshark/wireshark/-/merge_requests/22275 > [3] > https://lists.wireshark.org/archives/wireshark-dev/201306/msg00101.html > [4] https://gitlab.com/wireshark/wireshark/-/merge_requests/21941 > > > > _______________________________________________ > Wireshark-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
