Windows: MSYS/MinGW64 builds does not generate sixel image output in native MSYS/mintty terminal

[eabase]

I have managed to compile the code herein, using MSYS in the MINGW64 environment.

The resulting img2sixel.exe work fine, when running in Powershell (pwsh 7.5.2) within Windows Terminal. However, when using the same binary (exe), in the native MSYS/MINGW64 terminal, the code seem to run, but no output is generated.

In addition, the "debug message" seem to be always turned on against compiler (configure) specifications, so something else must be going on.

This is the only output I get:

For the details about compiling and the various related issues, please look at these:

• I'm unable to build the windows (Windows 10 x64) binaries, could someone post them? #180
• Any solutions for using in Windows Terminal with powershell (pwsh)? #197
• mintty doesn't appear to support sixel graphics when using incompatible tools mintty/mintty#1252
• Set up Cygwin builds hpjansson/chafa#186
• ConPTY Passthrough mode  microsoft/terminal#1173 # ConPTY Passthrough mode

_{Also, I'm posting some of them as back-links from those to here.}

---

In addition, @Kreijstal mentioned:

you can build it on msys2, however there are some things that must be patched, I made a PR for the other libsixel fork, but never for this one..

Can you make a PR for the MSYS build compatibility in this repo?
Also, where is your code or PR located?

_{🚩 I think it would better if people stop using the other now archived repo.}

[saitoha]

@eabase As mentioned in the mintty issue, this problem is likely a problem with the ConPTY or Console API layer.
After trying various workarounds, I found that it works fine if I expand it into a single string at the shell level. I'm not sure why.

$ echo "$(./img2sixel.exe image.png)"

[j4james]

I'm not exactly sure how an MSYS shell works, but if it's like a separate OS, then it's probably opening a new conpty session in order to execute win32 executables. And when that happens, your content is getting processed by whatever version of conhost is bundled with Windows. If you're on Windows 10, that's going to be years out of date, and definitely won't be able to handle sixel. It might work on Windows 11 though.

[saitoha]

This issue is reproducible on my Windows 11 environment as well.
Incidentally, it seems that builds which depend on a cygwin1.dll built under Cygwin do not exhibit this issue. Interesting.

[saitoha]

Findings:

• The issue also occurs over SSH (≈ not a terminal-specific problem).
• It does not occur with Cygwin builds (binaries linked against cygwin1.dll / msys-2.0.dll).
• It does occur with binaries built in the MSYS2 UCRT64/MINGW64/CLANG64 environments using MinGW GCC/clang (occurs when going through ConPTY).
• Setting the $MSYS environment variable to disable_pcon works around the problem.

[mintty]

To display sixel output in mintty, simply cat it to the terminal. No need to disable_pcon as the ConPTY layer. Test with MSYS, also UCRT64.
(As a side-note, by the way, to display an image file like katze.jpg, you could also use the iTerm2 image protocol which mintty implements, e.g. using the showimg script from the mintty utils repo.)
What Windows-compiled (or MinGW) sotware does to output sixel controls is out of control of mintty. To debug the issue, mintty logging could be activated in order to see any additional escape sequences that might be emitted.

[eabase]

Awesome!

The weird formalism of sub-shelling the exe works in both Cygwin and MSYS/MINGW64:

echo "`./img2sixel.exe egret.jpg`"

• cat *.six - works in all (Powershell, Cygwin, MSYS)
• type ..\images\snake.six works in CMD
• ./img2sixel.exe egret.jpg | cat works in MSYS
• ./img2sixel.exe egret.jpg | cat does not work in Cygwin
• ./img2sixel.exe egret.jpg | cat >/dev/tty works in Cygwin
• .\img2sixel.exe egret.jpg - Works in Powershell (pwsh) and CMD in Windows Terminal
• MSYS=disable_pcon ./img2sixel.exe egret.jpg - works in MSYS
• MSYS=disable_pcon ./img2sixel.exe egret.jpg - does not work in Cygwin
• CYGWIN=disable_pcon ./img2sixel.exe egret.jpg - does not work in Cygwin

@mintty
Yeah, I guess we're not really interested in other terminals at this moment. Because if we can't get this to work seamless in native Win, MSYS and Cygwin, it will be hard for any other project to follow. OC we already know that just cating raw six to terminals in powershell and mintty works just fine, as I stated above. It's what's going on behind the scenes in Cygwin/Mintty Bash vs in MSYS Bash, when you run the *.exe and the output is to the terminal. I can't see a reason why these are handled differently?

From above experiments, it seem that MSYS is handling pipes differently than Cygwin...
What's their connection to Windows pipes?

ls -Force '\\.\pipe\*' | Where-Object { $_.Name -match 'cygwin|msys|conpty' } | Select Mode, Length, Name, ResolvedTarget | Sort Name | ft -AutoSize

Mode  Length Name                                         ResolvedTarget
----  ------ ----                                         --------------
-----      1 conpty-1988358.795246441-in                  \\.\pipe\conpty-1988358.795246441-in
-----      1 conpty-1988358.795246441-out                 \\.\pipe\conpty-1988358.795246441-out
-----      1 conpty-3287206.9207443856-in                 \\.\pipe\conpty-3287206.9207443856-in
-----      1 conpty-3287206.9207443856-out                \\.\pipe\conpty-3287206.9207443856-out
-----      0 conpty-3287206.9207443856-out-worker         \\.\pipe\conpty-3287206.9207443856-out-worker
-----      1 conpty-3483248.876075733-in                  \\.\pipe\conpty-3483248.876075733-in
-----      1 conpty-3483248.876075733-out                 \\.\pipe\conpty-3483248.876075733-out
-----      0 conpty-3483248.876075733-out-worker          \\.\pipe\conpty-3483248.876075733-out-worker

-----      1 cygwin-e022582115c10879-25152-sigwait        \\.\pipe\cygwin-e022582115c10879-25152-sigwait
-----      1 cygwin-e022582115c10879-46776-sigwait        \\.\pipe\cygwin-e022582115c10879-46776-sigwait
-----      1 cygwin-e022582115c10879-pty0-echoloop        \\.\pipe\cygwin-e022582115c10879-pty0-echoloop
-----      1 cygwin-e022582115c10879-pty0-from-master     \\.\pipe\cygwin-e022582115c10879-pty0-from-master
-----      1 cygwin-e022582115c10879-pty0-from-master-nat \\.\pipe\cygwin-e022582115c10879-pty0-from-master-nat
-----      1 cygwin-e022582115c10879-pty0-master-ctl      \\.\pipe\cygwin-e022582115c10879-pty0-master-ctl
-----      1 cygwin-e022582115c10879-pty0-to-master       \\.\pipe\cygwin-e022582115c10879-pty0-to-master
-----      1 cygwin-e022582115c10879-pty0-to-master-nat   \\.\pipe\cygwin-e022582115c10879-pty0-to-master-nat

-----      1 msys-dd50a72ab4668b33-22476-sigwait          \\.\pipe\msys-dd50a72ab4668b33-22476-sigwait
-----      1 msys-dd50a72ab4668b33-50772-sigwait          \\.\pipe\msys-dd50a72ab4668b33-50772-sigwait
-----      1 msys-dd50a72ab4668b33-pty0-echoloop          \\.\pipe\msys-dd50a72ab4668b33-pty0-echoloop
-----      1 msys-dd50a72ab4668b33-pty0-from-master       \\.\pipe\msys-dd50a72ab4668b33-pty0-from-master
-----      1 msys-dd50a72ab4668b33-pty0-from-master-nat   \\.\pipe\msys-dd50a72ab4668b33-pty0-from-master-nat
-----      1 msys-dd50a72ab4668b33-pty0-master-ctl        \\.\pipe\msys-dd50a72ab4668b33-pty0-master-ctl
-----      1 msys-dd50a72ab4668b33-pty0-to-master         \\.\pipe\msys-dd50a72ab4668b33-pty0-to-master
-----      1 msys-dd50a72ab4668b33-pty0-to-master-nat     \\.\pipe\msys-dd50a72ab4668b33-pty0-to-master-nat

[eabase]

Ok, I don't know WTF is going on, now all of the sudden (after having closed and reopened Cygwin),
one of the above commands that didn't work previously, now works:

# Works in Cygwin ??
./img2sixel.exe egret.jpg | cat

[mintty]

I can't see a reason why these are handled differently?

Windows-compiled programs likely use the Windows console API for their output, rather than writing to plain stdout.
Then the ConPTY layer may inject whatever it thinks to be witty. Analysis of mintty log (see above) may help.
Actually, there is an updated version of the ConPTY layer, just not yet deployed with Windows. You can patch it yourself, however. Would be good to know whether that helps: See the description of installing OpenConsole in
https://github.com/mintty/mintty/wiki/Tips#inputoutput-interaction-with-alien-programs

[elieux]

I spent a while digging into this and:

• this shouldn't be related to any weirdness in the outputting program itself, my testing program ended up using NtWriteFile (through fputs)
• CYGWIN=disable_pcon doesn't have an effect on the fly, but it does if it's set before launching the Cygwin process; I'm not sure why exactly MSYS2 differs in this, but it might be due to this change at a glance
• running in an unwrapped ConHost just prints the sequence interpreted as characters (subject to active codepage, see Chcp) because ENABLE_VIRTUAL_TERMINAL_PROCESSING is not set
• if the program sets ENABLE_VIRTUAL_TERMINAL_PROCESSING in its console, nothing is displayed
• which is also what happens when run from WSL, MSYS2 or Cygwin through ConPTY
• piping through Cat changes the result because now the output doesn't go through the console at all, it's just basic pipes
• if the program unsets ENABLE_VIRTUAL_TERMINAL_PROCESSING in its console, we go back to printing characters, even in WSL, MSYS2 and Cygwin through ConPTY
• the outlier here is Windows Terminal where some kind of ConPTY is involved, but the graphics is displayed, and this works regardless of setting or unsetting ENABLE_VIRTUAL_TERMINAL_PROCESSING; after skimming the Terminal source code, I agree with mintty here in that Terminal uses its own build of ConHost (OpenConsole) that somehow doesn't just eat the sequences; I don't want to fiddle with my system ConHost to test this, Terminal doesn't easily allow using system ConHost and didn't have the time to build my own version of Terminal

[mintty]

Finding this recent change in MSYS that supports the workaround was really an act of digging, I suppose :)
Thanks a lot for the analysis; the patch should be ported upstream to cygwin.

I don't want to fiddle with my system ConHost

I would test this if someone please gives build instructions for the img2sixel binary.

Terminal uses its own build of ConHost

Could you see whether Windows Terminal can use its own ConHost even if the legacy conhost is still installed in Windows? If so, I'd be highly interested in finding out how it would achieve that (so I could mimic the approach for mintty running WSL).

[elieux]

For the test case, I just used Type or Cat with some stored Sixel file for a bit, then I put the sequences into my own simple program to avoid dealing with Cmd, source code attached: text-test.zip

I looked around WT's code a bit and it seems it's somehow convincing Condrv that it can handle both sides of the console by creating custom handles, the src/host/srvinit.cpp, src/server/DeviceHandle.cpp, and src/winconpty/winconpty.cpp files seem most relevant. I'd like to experiment with it a bit, but I don't know when I'll get to it.

Could you see whether Windows Terminal can use its own ConHost even if the legacy conhost is still installed in Windows?

What exactly do you mean by "legacy conhost is still installed in Windows"? I haven't fiddled with anything in System32 and WT seems to be happily spawning its own OpenConsole.exe instead of ConHost.exe.

[mintty]

Your program, compiled with cygwin x86_64-w64-mingw32-gcc, works for me in both cygwin and MSYS.
So how would you compile it to not work?

WT seems to be happily spawning its own OpenConsole.exe instead of ConHost.exe.

Yeah, I meant how would it achieve that without fiddling in System32?

[j4james]

If you're asking how terminals on Windows can use a more modern version of conpty than the one included in the Windows system32 directory, you can look at the commits in other terminals that have done that.

• WezTerm
• Alacritty

But note that this only works when the terminal is responsible for starting the conpty session. If, for example, you've opened a WSL shell, and then run cmd.exe, that'll start a separate conpty session using the system conpty.dll, and not the one bundled with the terminal. This applies to Windows Terminal as well.

[eabase]

IDK, if this helps, but the imcat program output what seem to be sixel codes, that works in both the WT/pwsh and Cygwin/MSYS/Bash. Although imcat itself outputs shitty images.

The compile instructions for THIS code is here:

• I'm unable to build the windows (Windows 10 x64) binaries, could someone post them? #180 (comment)

The CMake compile instructions for imcat is here (and comment include a quasi patch):

• Building on Windows stolk/imcat#15

And the source code I used for the above imcat was from here:

• https://github.com/belfner/imcat/blob/master/imcat.c

@elieux
Also, I believe VT processing have been enabled by default on all Windows apps and terminals.
So if you say:

if the program sets ENABLE_VIRTUAL_TERMINAL_PROCESSING in its console, nothing is displayed

That may explain some of this behavior.
imcat above sets it in the program itself:

static void set_console_mode(void)
{
	DWORD mode=0;
	const HANDLE hStdout = GetStdHandle( STD_OUTPUT_HANDLE );
	GetConsoleMode( hStdout, &mode );
	mode = mode | ENABLE_VIRTUAL_TERMINAL_PROCESSING;
	SetConsoleMode( hStdout, mode );
	oldcodepage = GetConsoleCP();
	SetConsoleCP( 437 );   // IBM 437 !!
	doubleres = 1;
}

However, I see they also use code page for IBM 437 which is gonna break when windows defaults to use UTF-8.

In pwsh, my terminal settings looks like this:

IDK, what mintty does there, becuase it used to be that it was pwsh that was the trouble maker, and mintty always worked.

This issue shows how the fonts are not handled correctly (by imcat) in pwsh (fail) vs mintty (ok).

• Imcat seem to show wrong/broken fonts within image stolk/imcat#14

You may also wanna check your terminal coding with:

[console]::InputEncoding && [console]::OutputEncoding && $OutputEncoding && chcp