[Roland Knall <rknall@xxxxxxxxx>]

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 <wireshark-dev@xxxxxxxxxxxxx>:

(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 -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx