dynamic conpty loading

Greywolf greywolf@starwolf.com
Sat Nov 29 18:50:08 GMT 2025


On 2025-11-29 04:33, Takashi Yano via Cygwin wrote:
> Hi Thomas,
> 
> On Thu, 27 Nov 2025 17:52:33 +0100
> Thomas Wolff wrote:
>> 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
> 
> Thanks for testing.
> When do you get the error above?
> 
> In my environment, the patch works under Win11/Win10 with and without
> OpenConsole.exe installed.
> 
> Win32 error 299 is ERROR_PARTIAL_COPY, so child_copy copied only
> partially some reason. However, I don't change any code path for
> native cygwin program with this patch. Therefore, I believe the
> patch does not affect fork().
> 

Couple of things:

1.  Is a rebase necessary to work with this, perhaps?
2.  Should not .dll objects go to lib, not bin?


-- 
--*greywolf;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x2C80F168914E2DF6.asc
Type: application/pgp-keys
Size: 3090 bytes
Desc: OpenPGP public key
URL: <https://cygwin.com/pipermail/cygwin/attachments/20251129/46188f55/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://cygwin.com/pipermail/cygwin/attachments/20251129/46188f55/attachment.sig>


More information about the Cygwin mailing list