Issues with WindowsTerminal (WinCON, VT)

[HunterZ]

Splitting WinCon discussion from issue #234, per following suggestion:

When you say it was hard to get WinCon working : it shouldn't be any more difficult than WinGUI. Perhaps an issue for that as well? Generally speaking, I'd suggest WinGUI over WinCon; the latter is quite limited in comparison. But for one reason or another, a lot of people still seem to like WinCon, and we do try to keep it working.

So I ran into a number of issues with WinCon, which I will detail below. I don't expect that all or maybe even any of them are your fault, versus MSYS2 package maintainers, Windows 11 Terminal app quirks, etc., but I thought you might appreciate the notes at least:

First, the MSYS2 Mingw64 static library for some reason wouldn't link due to a PlaySound symbol error, so I had to switch to the DLL version. Confusingly, statically linking against libpdcurses_wingui.a has the same issue, even though it's the exact same file as libpdcurses.a, which itself works fine when linked in the exact same manner. This is probably all MSYS2's fault somehow.

After I waded through all that, I found that it seems to be impossible to programmatically resize the new Windows 11 Terminal app, so my output was all scrambled due to being based on very old code that assumes 80 columns. I even tried copy-pasting some Win32 API code, and it had no effect. Is there some way to get WinCon to create its own Console Host window instead of trying to use whatever window it was launched from?

When I did manage to get a correct-looking terminal size, some of my unicode characters still weren't showing up. I tried the non-Mod version of PDCurses and had the same problem there too, though, so it's probably somehow my fault or a problem with the new Windows 11 Terminal app. These characters do show up fine in WinGui mode, however. Maybe I just need to try some different fonts?

After all this, I decided that WinCon is just too fragile for my needs, at least on Windows 11. It's a shame, because unlike WinGui it does support beeps and shift+keypad.

[GitMensch]

Is there some way to get WinCon to create its own Console Host window instead of trying to use whatever window it was launched from?

No, only if you start a sub-process with explicit cmd /c start cmd /k.

After I waded through all that, I found that it seems to be impossible to programmatically resize the new Windows 11 Terminal app, so my output was all scrambled due to being based on very old code that assumes 80 columns.

I can second that, also happens on Windows 10 compiled with "good old mingw" (where you have to make INFOEX=N) - works with "free standing" cmd.exe/powershell.exe, doesn't work if cmd.exe/powershell.exe runs below WindowsTerminal.exe.
Also the initial size as reported to the application is wrong, so "bigger" consoles look scrambled (works with parts that are redrawn later) - this and the resize issue can be seen with testcurs.

Using the vt variant doesn't help, both issues are similar there.

Updating to newest [Windows Terminal Preview](https://github.com/microsoft/terminal/releases9 (currently v1.13.10395.0) made the "additional vt issues" a bit better, but did not changed much in general for both ports.

the MSYS2 Mingw64 static library for some reason wouldn't link due to a PlaySound symbol error

For WinCon you need to explicit link against -lwinmm.
I think this should be true for both the static and the shared version.
Did we miss to mention that in the port docs? Does it work when you do that?

[johnsonjh]

I understand your frustration here ... I've just finished playing with Windows and was disappointed, but it's not the fault of pdcurses.

The assumption that the "terminal" that is used for displaying the curses screen being the same as that which is displaying the non-curses display, and that being the same as that from which the application was launched doesn't hold true, which causes some issues. (This is the case with DOSVGA as well.)

For example, on the Win32 version of the G Editor, the biggest "problem" is that the output from ! commands, and other things like help are displayed in the originating text window, not the curses window. I think I'm just going to have to improve this for a proper Windows experience, with a curses-based help display and output capture on Windows. Otherwise, help and similar are just especially clunky.

Now, I remember, I actually removed the PlaySound reference too - I wanted to avoid linking winmm, since BELL functionality wasn't something I wanted or needed.

Perhaps that can be made an "official" conditional?

[HunterZ]

For WinCon you need to explicit link against -lwinmm. I think this should be true for both the static and the shared version. Did we miss to mention that in the port docs? Does it work when you do that?

Could have sworn I tried that, but you're right - it absolutely works. Thanks!

Also verified that my missing characters issue was due to Windows Terminal defaulting to an apparently lackluster font in terms of unicode support.

Discovered a keyboard quirk with WinCon: PDC_get_key_modifiers() returns zero when typing on the number pad with numlock enabled. This blocks any ability to differentiate whether the user entered a number via the keypad or the regular number row.