Re: dynamic conpty loading

Am 05.12.2025 um 12:11 schrieb Corinna Vinschen via Cygwin:
> On Dec  5 18:52, Takashi Yano via Cygwin wrote:
>> On Thu, 4 Dec 2025 12:01:58 +0100
>> Corinna Vinschen wrote:
>>> Aren't from here on two patches folded into one?  All but one hunk (the
>>> one calling CreatePseudoConsole_new) seem to be entirely independent of
>>> OpenConsole.
>> This part is necessary to work with OpenConsle.exe. OpenConsole.exe uses
>> also ESC[c during startup while conhost.exe uses only ESC[6n.
> Ok, but ESC[c is a stock vt100 sequence.  Admittedly, I have no idea if
> there are other terminals out there which use this sequence at startup,
> too...
>
>>>> -      static const int wpbuf_len = strlen ("\033[32768;32868R");
>>>> +      static const int wpbuf_len = 64; /* for response to CSI6n nad CSIc */
>>> Is there some macro for the count of 64 in this context, by any chance?
>> I'm not sure for now that 64 is really enough for the responce to ESC[c.
>> mintty returns about 30 byte responce. But some other terminal may return
>> longer responce.
> Per the vt100 documentation, the response is supposed to be
>
>    ESC [ ? 1 ; Ps c
>
> with Ps being a character in the range 0 - 7.
>
> Just being curious, what are mintty and OpenConsole returning?
mintty default response is ESC [ ? 64;2;4;6;9;11;15;21;28;29;52 c
with some variations if you configure a terminal type beginning with 
"vt"; also indicators of disabled features will be dropped with the next 
release

>>>> [...]
>>>> if [ $(uname -m) = "x86_64" ]
>>>> then
>>>> 	POSTFIX="x64"
>>>> else
>>>> 	POSTFIX="x86"
>>> Do we really want a 32 bit version?  Isn't there an aarch64 version?
>> No.
> Weird.  But Windows on AArch64 supports a x86_64 emulation, iiuc.
>
>> What should we assume result of "uname -m" in aarch64 machine?
> "aarch64" :)
>
>>> For a start, this may be ok, but we should really try to build our own
>>> OpenConsole package build by our own gcc or clang, IMHO.
>> OpenConsole.exe also uses WIL, so it looks not easy to build it in cygwin
>> environment.
>>
>> Maybe just getting it from https://github.com/microsoft/wil/ is enough,
>> but I have not tried it yet.
> Oh, wow!  Looks like fixes to build WIL on MingW have been merged just a
> couple of hours ago.
>
>
> Corinna
>


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple