On Mon, Aug 22, 2022 at 9:37 PM Jirka Novak <j.novak@xxxxxxxxxxxx> wrote:
> >> What do you think about that options?
> >
> > I have no idea why you didn't even consider sending CTRL_BREAK_EVENT
> > using GenerateConsoleCtrlEvent() as a graceful shutdown mechanism on
> > Windows. Wireshark creates all extcaps with a hidden console window
> > (CREATE_NEW_CONSOLE and SW_HIDE flags set).
> >
> > CTRL_BREAK_EVENT is really simple to handle on extcap side, as it only
> > requires calling SetConsoleCtrlHandler() to register a handler. The
> > handler will be called in separate thread (unlike UNIX signals), but
> > the issues related to the separate thread are exactly the same in any
> > of the three methods you proposed. Registering handler is really an
> > opt-in, as the default handler simply terminates the process.
>
> I'm sorry, my understanding was it is in !2063. I was wrong, I will try it.
The problem with GenerateConsoleCtrlEvent() is that the caller has to
be attached to the target process console. While we could technically
do so, it requires freeing any already open console because process
can be attached to at most one console. The pretty much only sane
solution to the problem is to have a helper program between Wireshark
and extcap.
The helper would simply spawn extcap with provided parameters and
accept commands from Wireshark e.g. on pipe. The commands would be to
gracefully terminate (CTRL_C_EVENT or CTRL_BREAK_EVENT) and forcefully
terminate (TerminateProcess()). Note that the helper must not be
forcefully terminated as it would leave the extcap running.
While far from ideal, I think the helper is the only sensible
approach. Note that GLib gspawn-win32-helper does something different,
so going back to the GLib helper is not what this is all about.
Best Regards,
Tomasz Moń