[Bug 55197] New: ReadConsole blocks handler routines

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55197

Bug ID: 55197
           Summary: ReadConsole blocks handler routines
           Product: Wine
           Version: 8.11
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Created attachment 74792
  --> https://bugs.winehq.org/attachment.cgi?id=74792
Small example calling SetConsoleCtrlHandler + ReadConsoleA

Handler routines, set via SetConsoleCtrlHandler, are not executed when using
ReadConsoleA.

When pressing <CTRL>+<C> in the attached source, the handler routine should get
executed and print something.

Current wine master only returns from ReadConsoleA and prints nothing.

[Bug 55197] ReadConsole blocks handler routines

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55197

Eric Pouech  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Eric Pouech  ---
normally, https://gitlab.winehq.org/wine/wine/-/merge_requests/3310 should take
of this bug

[Bug 55197] ReadConsole blocks handler routines

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55197

--- Comment #2 from Maarten  ---
I tried https://gitlab.winehq.org/wine/wine/-/merge_requests/3310 and have the
following remarks:
- the message "CTRL-C" event should get displayed multiple times. Once for
every time CTRL+C is pressed. In the patched wine, it only prints "CTRL-C
event" again after pressing ENTER in between.
- CTRL+Break should also cause a message to be displayed. On a 32-bit winxp
qemu VM, it causes the test executable to exit.

[Bug 55197] ReadConsole blocks handler routines

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55197

--- Comment #3 from Eric Pouech  ---
(In reply to Maarten from comment #2)
> I tried https://gitlab.winehq.org/wine/wine/-/merge_requests/3310 and have
> the following remarks:
> - the message "CTRL-C" event should get displayed multiple times. Once for
>
> every time CTRL+C is pressed. In the patched wine, it only prints "CTRL-C
> event" again after pressing ENTER in between.

it's called several time, but there's likely a(nother) bug which makes print
the message at the very same position (probably not handling the \n from the
printf in handler)
> - CTRL+Break should also cause a message to be displayed. On a 32-bit winxp
>
> qemu VM, it causes the test executable to exit.

calling back the handler likely won't be supported
it does terminate the app though
from a unix terminal, you're supposed to use ctrl-\ instead of ctrl-break

[Bug 55197] ReadConsole blocks handler routines

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55197

--- Comment #4 from Maarten  ---
> from a unix terminal, you're supposed to use ctrl-\ instead of ctrl-break

Thanks, I didn't know wine mapped CTRL+Break to CTRL+.
Should wine run the CTRL_CLOSE_EVENT handler then CTRL+\ is pressed (or SIGQUIT
is pressed)?

[Bug 55197] ReadConsole blocks handler routines

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55197

Ken Sharp  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download, source

[Bug 55197] ReadConsole blocks handler routines

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55197

--- Comment #5 from Eric Pouech  ---
> Should wine run the CTRL_CLOSE_EVENT handler then CTRL+\ is pressed (or
> SIGQUIT is pressed)?

what I meant in comment #3 is that adding support for passing back to handler
the various events will require an important rewrite of that part, and I'm not
sure it'll happen soon
(for the detail, the ctrl-c (resp ctrl-break or ctrl-) from windows world are
passed to process in the process groups with kill SIGTERM (resp SIGQUIT).
this has the following limitations:
- hard to add more events (like CTRL_CLOSE_EVENT) as signal as no parameter
- impossible to discriminate between console generated event => unix signal and
other internal use (like kernel32.TerminateProcess())
to it'll require to put in place another channel to send console event to
process. don't hold your breath on that feature.