[CYGWIN] win32 demos don't work "redirection not supported"

[GitMensch]

No matter what makefile options (for gccwin32.mak) were used to compile PDCurses.

[Bill-Gray]

Do the recent changes for Cygwin do anything to resolve this, now using mingwin32.mak? (As commented elsewhere, I'm thinking gccwin32.mak may now be obsolete.)

[GitMensch]

In win32 variant we currently need both and I now at least understood why:

• gccwin32.mak - for use in a posix-shell in Windows (only Cygwin intended)
• mingwin32.mak - for use in a cmd window when build on Windows

... and I've retested gccwin32.mak of win32 just now: cygwin32 still returns Redirection is not supported. when calling testcurs.exe while it works with cygwin64.
The first difference I've spotted: my local cygwin64 installation uses TERM=cygwin while the old (and quite often updated) cygwin installation uses TERM=xterm. When I change this to TERM=cygwin the error message goes away but the test executables still do nothing and return 127. May be a local issue, I'd need to re-install cygwin for verifying this but I'd like to not do it if possible - and in any case see a workaround if possible.

[GitMensch]

... and running the testcurs.exe + dlls of win32 variant built with my local cygwin installation + cygwin-1.dll directly (=not in the cygwin console) results in "could not start the application (0xc000007b)".

[GitMensch]

Just tested this with a debug run:

Reading symbols from testcurs.exe...done.
(gdb) run
Starting program: /d/dev/PDCurses.git-svn/win32/testcurs.exe
[New Thread 14636.0x1170]
[New Thread 14636.0x2638]
[New Thread 14636.0x2344]
[New Thread 14636.0x1f6c]
[New Thread 14636.0x2324]
gdb: unknown target exception 0x406d1388 at 0x75d45722

Program received signal ?, Unknown signal.
0x75d45722 in RaiseException ()
   from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(gdb) backtrace
#0  0x75d45722 in RaiseException ()
   from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#1  0x61081614 in SetThreadName(unsigned long, char const*) ()
   from /usr/bin/cygwin1.dll
#2  0x61004a6b in cygthread::create() () from /usr/bin/cygwin1.dll
#3  0x61004b5f in cygthread::async_create(unsigned long) ()
   from /usr/bin/cygwin1.dll
#4  0x77a5ae69 in ntdll!RtlCaptureStackContext ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x77a40dd4 in ntdll!KiUserApcDispatcher ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x61004b50 in cygthread::create() () from /usr/bin/cygwin1.dll
#7  0x00000000 in ?? ()

... but I also get fork errors when trying to run help2man (and an update of cygwin + rebase-trigger fullrebase didn't changed anything other than more disk space needed). Everything that uses threads and sometimes stuff that uses fork seems to just not work there. The Cygwin website suggests "use the 64 bit version if possible".
I may remove the 32 bit version from my local machine completely...

But the strange thing: win32a works like a charm in this environment, just win32 doesn't work,,,

[wmcbrine]

The problem is that the Cygwin environment uses its own console window thingie, "mintty", that supports classical Unix-y escape sequences, but not the Windows Console API used by the "win32" port of PDCurses. There are at least a couple of workarounds:

1. Start console apps like so: "cmd /c start testcurs". This will create a new, proper console window that closes when the app terminates.

2. Instead of the Cygwin terminal, open a regular command shell, and run Cygwin.bat. Then you can run both Windows Console apps and Cygwin's stuff... there's probably a down side, but I haven't observed it yet.

win32a works because apps built with it are not console apps.

[GitMensch]

@wmcbrine Thank you for these notes, using cmd.exe /c "start testcurs.exe" (or more safe cmd.exe /c "start "testcurs.exe"") works fine (won't work without the "`). And yes: of course the wingui (formerly win32a) variant works.

I think this can be closed now.

[Bill-Gray]

I don't have a Cygwin environment, and hence no mintty, and didn't know it supported the classical escape sequences. A bit of searching reveals that it's xterm-compatible. Which means the new VT flavor ought to work on it nicely, probably supporting some features Wincon wouldn't handle anyway. I'll give it a try and will see what happens.

[GitMensch]

Actually I've just tested it the first time under MINGW64 (works in general, no blinking and other stuff seems to be broken [or not yet implemented], too):
- I don't know if "click" is already supported with vt, doing a bunch of times the result is (each time you get some characters adding to the output - important: this behavior stays even after newtest.exe was closed [by CTRL+C because I found no other way of closing it]):

On running testcurs the cursor up/down doesn't work (changes the cursor position instead of returning the event).

Note: the "obvious" build problem is that vt/Makefile doesn't have an extension for the demos which leads to failing strip (we could get it in dynamically and won't need an extra Makefile).

I assume cygwin behaves identical, testing next.

[GitMensch]

Of course we have the exe-part, it just isn't set automatically. we could add the part from wingui/Makefile.mng to vt/Makefile:

ifneq (,$(findstring CYGWIN,$(uname_S)))
	#  Insert Cygwin-specific changes here
	ON_WINDOWS = 1
endif
ifneq (,$(findstring MINGW32_NT,$(uname_S)))
	#  Insert MINGW32-specific changes here
	ON_WINDOWS = 1
endif
ifneq (,$(findstring MINGW64_NT,$(uname_S)))
	#  Insert MINGW64-specific changes here
	ON_WINDOWS = 1
endif

In the meantime manually adding EXE=.exe when invoking make serves as a workaround.

[GitMensch]

The vt flavor works much better in Cygwin than in MinGW64:

Function keys (including cursor) and mouse works fine (despite than missing blinking, missing change of cursor, but those may not be implemented, are they?)

Interestingly starting a new PDCurses (vt) application shows the screen from the last one. Does this happen in a normal terminal environment, too?

[Bill-Gray]

@GitMensch - very interesting...
I've just tried getting the VT flavor to run under plain vanilla Win10. Enabling use of console codes requires one to set the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag via SetConsoleMode. When I did that, using the code currently at https://www.projectpluto.com/xfer/pdcscrn.c , Newtest displayed correctly. Some work needs to be done on that; the new code really only ought to be compiled (I think) for plain vanilla Win10. As you've demonstrated, other consoles handle VT control codes without needing to have any bits reset.
I see that input in Windows (any flavor) is handled using conio.h and the kbhit() function, which is deeply unlikely to work. We would probably have to copy over at least some of the logic from the WinCon flavor.
Also, the screen size wasn't correctly detected; the upper 25x80 area was used, even though the cmd.exe window was considerably larger than that.
We're also missing the clipboard functions, but for those, we can just compile pdcclip.c from either WinCon or WinGui (they're identical). I've code afoot to enable these functions in X11-land as well.