[PATCH v4 0/4] Add support for OpenConsole.exe

[Johannes Schindelin]

Hi Takashi,

On Fri, 6 Mar 2026, Takashi Yano wrote:

> On Tue, 3 Mar 2026 12:03:25 +0100 (CET)
> Johannes Schindelin wrote:
> > 
> > On Sat, 28 Feb 2026, Takashi Yano wrote:
> > 
> > > v4:
> > >   * Do not close pi.hProcess in CreatePseudoConsole_new()
> > >   * Modify handling of CSIc response
> > > 
> > > Takashi Yano (4):
> > >   Cygwin: pty: Use OpenConsole.exe if available
> > >   Cygwin: pty: Update workaround for rlwrap for pseudo console
> > >   Cygwin: pty: Add workaround for handling of Ctrl-H when pcon enabled
> > >   Cygwin: pty: Fix the terminal state after leaving pcon
> > 
> >  Three out of these four patches seem to be workarounds for bugs in
> >  OpenConsole.exe. The project is open-source and accepts PRs. Would it not
> >  make _much_ more sense to contribute fixes for those bugs?
> 
> Yeah, indeed. However, ...
> 
> Cygwin: pty: Update workaround for rlwrap for pseudo console
> This is not a bug of OpenConsole.exe. This is for translation
> between POSIX terminall attribute and console mode.

Okay... I guess ;-)

> Cygwin: pty: Add workaround for handling of Ctrl-H when pcon enabled
> This may be a bug, however, by any chance, an intended behaviour.

The workaround, however, looks as if it invites problems. It's just going
too far into hack mode. It's assuming too much about being the single
actor.

If there is any chance, any whatsoever, to avoid this workaround, I think
we'll be a lot better off.

> Cygwin: pty: Fix the terminal state after leaving pcon
> Perhaps, this does not occur if the pseudo console is used as
> suggested by Microsoft.

Still. It is way too hacky, as it over-focuses on one particular mode that
might be stuck, who knows what other terminal modes might need the same
treatment "just in case". Even with just this single mode, a proper fix in
OpenConsole.exe would be much preferable, as it leaves a lot less room for
future regressions.

> Anyway, for now, since I don't succeed to build OpenConsole.exe
> in my environment, it is dificult to debug it by myself.

Admittedly I struggled with this, too. After cloning
https://github.com/microsoft/terminal I followed the documentation in
`docs/building.md` how to build in PowerShell.

In addition to the documented `git submodule update --init`, also needed
to run `nuget restore` and `dotnet restore`.

The I had to use PowerShell 7, a regular Windows PowerShell won't do. Even
after that, it failed the build (symptom: missing vcpkg dependencies), and
I had to launch my Visual Studio 2022 Community instance which pointed out
that I needed the WinUI workload (a hefty ~1.9G download).

Even after that, the build was failing because of "C1076: compiler limit:
internal heap limit reached": Apparently the default configuration is to
use a _massively_ parallel build which brings my poor little laptop to its
limits. I did manage, though, via this command-line (suggested by Claude
Opus 4.6 when I set it to the task of fixing that build):

  Invoke-OpenConsoleBuild /p:Platform=x64 /p:Configuration=Debug /m:4 /p:ProcessorNumber=2

Note: I just verified that I could build it, I did not run any tests nor
did I look into the Ctrl+H problem yet.

Ciao,
Johannes