dynamic conpty loading

[Takashi Yano]

On Thu, 27 Nov 2025 17:20:26 +0900
Takashi Yano wrote:
> On Wed, 26 Nov 2025 19:50:07 +0100
> Thomas Wolff wrote:
> > 
> > Am 26.11.2025 um 11:32 schrieb Takashi Yano via Cygwin:
> > > On Fri, 21 Nov 2025 17:58:01 +0100
> > > Thomas Wolff wrote:
> > >
> > >> Am 21.11.2025 um 17:46 schrieb Corinna Vinschen via Cygwin:
> > >>> Hi Thomas,
> > >>>
> > >>> On Nov 21 16:46, Thomas Wolff via Cygwin wrote:
> > >>>> Am 21.11.2025 um 11:04 schrieb Takashi Yano via Cygwin:
> > >>>>> On Sun, 5 Oct 2025 10:15:55 +0200
> > >>>>> Thomas Wolff wrote:
> > >>>>>>>> The procedure seems to be:
> > >>>>>>>> try LoadLibrary("conpty.dll"), (if not successful, fallback to
> > >>>>>>>> GetModuleHandle("kernel32") instead) to retrieve GetProcAddress for
> > >>>>>>>> CreatePseudoConsole, ResizePseudoConsole, ClosePseudoConsole, and
> > >>>>>>>> then somehow (?) use those while calling CreateProcess.
> > >>>>>>>> The latter is woven into the cygwin library and I don't think it's a
> > >>>>>>>> good idea to clone that out of cygwin for a patched process creation
> > >>>>>>>> in mintty.
> > >>>>>>>>
> > >>>>>>>> My question/suggestion:
> > >>>>>>>> Can a cygwin mode switch to a selected conpty library instead of the
> > >>>>>>>> default one please?
> > >>> Where do you expect this conpty.dll to reside?
> > >>>
> > >>> If we do something like that, I would suggest to make sure that this
> > >>> conpty.dll is in a well-defined place. /bin or /lib might be a good
> > >>> idea. And if it exists in this defined place, it will be used by Cygwin.
> > >>>
> > >>> We can tweak the autoload mechanism to allow a primary DLL and a fallback
> > >>> DLL, that drops the need to set the CYWIN env var.
> > >>>
> > >>> The mintty package could contain a post-install script, or some other
> > >>> script in /bin to allow a user with admin rights downloading the latest
> > >>> (or the most sensible) conpty.dll from MSFT.
> > >>>
> > >>> Would that make sense?
> > >>>
> > >>>
> > >>> Corinna
> > >>>
> > >> That makes much sense, yes, thank you. /bin/conpty.dll would probably be
> > >> a good place.
> > > I checked the source of conpty.dll
> > > https://github.com/microsoft/terminal/blob/main/src/winconpty/winconpty.cpp
> > >
> > > conpty.dll seems to launch OpenConsole.exe in the directory where
> > > WindowsTerminal is installed.
> > > However, BUILTIN\Users does not have permission to execute OpenConsole.exe.
> > >
> > > Do you have some idea how to solve this problem?
> > > WindowsTerminal itself can launch OpenConsole.exe, so there should be
> > > some solutions, I think.
> > Did you install the nuget package? It can be extracted with zip, so you 
> > can install OpenConsole as a normal program...
> > I did not find a way, though, to invoke it explicitly so that it would 
> > solve the pty interworking problems.
> 
> Thanks.
> 
> I've made an experimental patch against fhandler/pty.cc and
> draft package named openconsole that installs official OpenConsole.exe
> binary into /usr/bin.
> 
> I confirmed the patch with openconsole package enables the mouse
> support for vim91 and neovim 0.8.0 (native windows binary) in
> pseudo console.
> 
> Any comments and suggestions would be appreciated.

openconsole-1.23.12811.0-1.cygwin.patch fixed.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openconsole-1.23.12811.0-1.cygwin.patch
URL: <https://cygwin.com/pipermail/cygwin/attachments/20251127/d7b8f59a/attachment.ksh>