WinCon/pdcscrn.c: support stdio redirections

[rhaberkorn]

• Instead of querying STD_INPUT_HANDLE/STD_OUTPUT_HANDLE to get the console handle, always open CONIN$ and CONOUT$, which works even after redirecting stdin/stdout. See also https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea#consoles
• This fixes e.g. SciTECO's --stdin/--stdout when used in combination with its interactive mode.
• It's an open question whether this approach is supported by ancient Windows versions as well.
• While this will fix applications that work with stdin/stdout besides or before using the Curses API, you will not of course capture any escape sequences when redirecting stdout as asked for in win32 variant not usable without "real" sysout #50.
• Of course we might say that you have to pass in console handles via newterm(), as you would do on ncurses, but the API is expecting FILE* instead. As long as you cannot effectively pass in your own console handles, this patch shouldn't make anything worse. See also infinity cycle in screen initialization, when pdcurses app is used as pager #256.

[Bill-Gray]

That looks lovely to me. I notice that the code involved is identical to that in PDCurses; this may be of interest to @wmcbrine. Tested by modifying testcurs.c thusly :

--- a/demos/testcurs.c
+++ b/demos/testcurs.c
@@ -238,6 +238,14 @@ int main(int argc, char *argv[])
                 case 'l': case 'L':
                     setlocale( LC_CTYPE, argv[i] + 2);
                     break;
+                case 's':
+                    {
+                        char tbuff[200];
+
+                        if( fgets( tbuff, sizeof( tbuff), stdin))
+                           printf( "Got a line\n%s", tbuff);
+                    }
+                    break;
 #ifdef __PDCURSESMOD__
                 case 'b': case 'B':
                     PDC_set_blink( TRUE);

and running testcurs < pdcscrn.c > z.txt. That causes z.txt to have the expected output. I could still run testcurs normally (hit cursor keys to select an item, etc.).

The only question in my mind is : should this be merged before 4.5.3 is released, or after? See issue #335 . I've enough confidence in it to say go ahead and merge it, but will wait a bit for comments.

Thank you. Nice to have a resolution to this problem; it's been dangling over us for some years now, as is apparent from the range of issues to which you linked.

[rhaberkorn]

Nice to hear. I would suggest to test it on the oldest Windows version you are still trying to support. (What would that be, Windows 2000? XP?)

[GitMensch]

As it doesn't get worse than before, I'd say get it in, maybe even mark #50 (and similar others) as solved by this.

[Bill-Gray]

I would suggest to test it on the oldest Windows version you are still trying to support.

A fair point. All I've tested it with is Wine. I have a Win10 box and (feel free to shudder here) a WinME box; I'll give it a go on both. Might be a day or so, though...

I suspect WinCon and WinGUI would work even on Win95, but lack a suitable machine and would not go to great lengths to support such ancientness.

[rhaberkorn]

I have a Win10 box and (feel free to shudder here)

Actually I tested in a Win 10 VM. It's the oldest that will still host MSYS.

[GitMensch]

I wanted to give it a try on Win95 (+fixcpu patch + retrozilla to access anything [giuthub doesn't work, of course)... but:

• this PR does not include the testcurses change - @Bill-Gray can you just add it?
• looks like only Appveyor provides binaries, and there are none for MinGW (Can they be added? You can have a cached version of old MinGW which will also lead to testing with older compilers)
• note: Appveyor OpenWatcom needs OW runtime files, which are missing in the lib folder (or an extra folder that could be added): clbr20.dll (C library) and mt7r20.dll (Math library, possibly not needed for PDCM)
• another note: I did not have success running GCC from my MinGW backup on Win95 either - it has a link to fstat64 in MSVCRT.dll, something that came later (98/ME? not sure)

[Bill-Gray]

Works on WinME [0], so I'm merging it.

Then I'll add the test lines for testcurs.c (exactly the patch shown above), update HISTORY.md and version constants in curses.h, push the changes, and make a release.

[0] I did have to make some minor changes to appease the elderly MSVC. But none of it affects anything 'current'. I'll add those minor changes, but don't think WinME support is important enough to hold up this release.

[GitMensch]

That sounds good. What MSVC did you test with (I guess 2003/.NET or 2005) and what kind of changes did you need?
... if you already have done them, then possibly just include them - one day more for the release really does not matter :-)

[rhaberkorn]

Works on Win95 [0], so I'm merging it.

Wow. I wasn't even hoping for anything that ancient. What about Win32s on Windows 3.11? Just kidding. ;-)

[Bill-Gray]

Changes now posted. I misfired in my original comment (now corrected); the testing was done on WinME, not Win95. I used MSVC 5.0, OpenWATCOM, and Digital Mars for WinCon and WinGUI on that platform. I also used those last two to compile the DOS and DOSVGA ports.

The changes mostly involved casting issues and unsupported features/functions (snprintf(), _beginthread(), etc.) There were some spurious compiler warnings that I think just reflect a somewhat more primitive state of the compiler art back in the late 1990s.

I actually did rummage around a bit looking for a hard drive that has (I think) a working install of MS-DOS, Win3.1, and MSVC 1.0, without success. But I've probably wasted enough time on this silliness anyway... though testing it on WinME, as on Wine, could have turned up bugs that would not otherwise be obvious. And I could imagine a retro-computing enthusiast getting some use out of it. So it's not really a complete waste of time.

[GitMensch]

I've guessed you tested with WinME. I've also joined the retro-fun and got Win95+FixCPU+IE5.5+some updates running but stopped after finding I need the vcredist6 update to use RetroZilla (which seems to be the only option to use HTTPS, which is nearly everywhere) and installing that update led some programs and/or the VM to crash.
I'll likely get back to that some later day, likely by putting anything needed (like unzip tools and some downloads) to an ISO and mount that, as that works well.

I also guess that you have either QEMU set up or on your "should be done someday" list. In this case you may want to check out https://github.com/rtts/win311 (just mount the HDD and have Win 3.11 running), if you want to test OpenWatcom 16bit builds there or additionally install MSVC 1.52c (or, you know, just "retro around").

In any case: thanks for the release which now builds again on MSYS2 msys2/MINGW-packages#24608 (and will likely be available soon in its package repository, note that MSYS2 dropped mingw32). Sadly it does not build with "old MinGW" any more:

cd wincon && make INFOEX=N CHTYPE_64=Y DEBUG=Y DLL=Y DLLNAME=libpdcurses LIBNAME=libpdcurses.dll"
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/addch.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/addchstr.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/addstr.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/attr.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/beep.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/bkgd.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/border.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/clear.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/color.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/debug.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/delch.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/deleteln.c
gcc -c -Wall -Wextra -pedantic -g -DPDCDEBUG -I.. -DPDC_DLL_BUILD ../pdcurses/getch.c
../pdcurses/getch.c: In function 'PDC_millisecs':
../pdcurses/getch.c:439:5: warning: implicit declaration of function 'clock_gettime' [-Wimplicit-function-declaration]
     clock_gettime( CLOCK_REALTIME, &t);
     ^
../pdcurses/getch.c:439:20: error: 'CLOCK_REALTIME' undeclared (first use in this function)
     clock_gettime( CLOCK_REALTIME, &t);
                    ^
../pdcurses/getch.c:439:20: note: each undeclared identifier is reported only once for each function it appears in
make: *** [getch.o] Error 1
Command exited with code 2

and the only workaround is to either adjust the makefile (because PDCCFLAGS only applies to osdir, but not srcdir) or getch.c (I'll make a new issue out of that).

[rhaberkorn]

I personally when testing on legacy OS, would have just built it with a modern MinGW or OpenWatcom with the necessary flags to make it compatible. IMHO you don't really need to support a development environment on Win95.

[GitMensch]

Do you have a list of the options (defines and possibly linking options) for older environments? Note: Modern MinGW (at least anything MSYS2) can only compile "down" to Windows 10, not sure what MinGW on Linux supports. "old plain MinGW" should be able to compile down to Win95, if you pass the right defines/linker options.
Not sure what OpenWatcom can compile down to.

Note that with neither wingui nor wincon there is a "direct way" to pass some flags... though both std and -D can be likely defined as part of CC...