dynamic conpty loading

[Thomas Wolff]

Am 27.11.2025 um 15:04 schrieb Takashi Yano via Cygwin:
> 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.
Thanks, I've tried to build latest newlib-cygwin with the 0001-... patch 
but then I'm getting this:

       0 [main] bash 27975 child_copy: dll data read copy failed, 
0x7FFA4C7CE000..0x7FFA4C7E7C90, done 0, windows pid 22444, Win32 error 299
                                                                  0 
[main] -bash 27950 dofork: child -1 - forked process 22444 died 
unexpectedly, retry 0, exit code 0xC0000005, errno 11
                         -bash: fork: retry: Resource temporarily 
unavailable

[Note: not available for testing until next week]
Kind regards,
Thomas