Re: [PATCH] Fix backspace key in Windows console driver

[Pavel Fedin]

On 07.07.2023 10:54, Thomas Dickey wrote:
> some.  I generally work on ncurses on Saturdays, unless responding to something
> that packagers would regard as urgent.  The recent work on manpages took time,
> as well.

 Not really a problem, just asking.

> On Windows, I've more than one environment to consider, and there are two
> driver configurations

 This is an "old", production driver. I've seen the new one, but, since 
that's experimental, i didn't do anything there.

 Just FYI, MinGW configure options are:

  ../${_realname}-${_base_ver}-${_date_rev}/configure \
    --prefix=${MINGW_PREFIX} \
    --mandir=${MINGW_PREFIX}/share/man \
    --build=${MINGW_CHOST} \
    --host=${MINGW_CHOST} \
    --target=${MINGW_CHOST} \
    --without-ada \
    --with-cxx \
    --with-shared \
    --without-pthread \
    --disable-rpath \
    --enable-colorfgbg \
    --enable-ext-colors \
    --enable-ext-mouse \
    --disable-symlinks \
    --enable-warnings \
    --enable-assertions \
    --disable-home-terminfo \
    --enable-database \
    --enable-sp-funcs \
    --enable-term-driver \
    --enable-interop \
    --enable-widec \
    --enable-pc-files \
    --with-pkg-config-libdir=${MINGW_PREFIX}/lib/pkgconfig

> For development/testing of this feature, my configuration was unsatisfactory
> (Windows 10 and 11 have only made the process for running console windows
> more cumbersome),

 I can give you more hints. Yes, there is lots of MinGW specifics:

1. If $TERM isn't set to empty string, ncurses tries to use old good 
terminfo and control codes instead of the API driver. And it fails to 
load the terminfo db because configure puts "/usr/share/terminfo" as 
path (no Windows-translated), which, obviously can't be accessed.

2. If (1) is fixed (that's easy, i tried it), ncurses succeeds loading 
terminfo; but there's some internal clash, and the screen is garbled 
beyond recongition. Some (long) time ago i experimented with that at 
work; and it worked, but Windows was XP back then. And i know MS has 
basically reengineered the console, so it now can process (some) control 
codes by itself. So, perhaps, there's some collision between Windows' 
own and ncurses' processing.

3. (2) isn't actually relevant; because Cygwin (and MSYS, as a 
consequence) has employed full Windows PTY support couple years ago. 
It's not experimental any more; and enabled by default. So one can run 
any Windows console app from within MinTTY; and it will work just fine; 
MinTTY will interpret app's API calls using WinPTY and act accordingly. 
The same works over ssh in Cygwin (Cygwin is server side; i'm routinely 
using it for remote work). So, bottom line, you aren't limited to native 
Windows cmd.exe if you want to run native Windows console apps 
(including ncurses with driver). So relying on $TERM is basically a 
thing of a past on Windows. In fact i still have my old experimental 
patch in the office somewhere, which uses GetConsoleMode() to check 
whether stdout handle is a console: 
https://stackoverflow.com/questions/22972071/is-there-a-way-to-determine-whether-stdout-is-pointing-to-the-console#22972460 
. If you're interested, i can try digging it out.

4. Cygwin (and MSYS) are also irrelevant. They want to be as UNIXy as 
possible, so, AFAIK, ncurses is built without driver support there. It 
relies solely on MinTTY's ability to interpret control codes and emulate 
a terminal. Somehow the problem, which i described in (2), doesn't 
appear there. Perhaps Windows console is very smart, i don't know. I 
also may be not up to date here, please correct my knowledge if so.

 Hope this helps.

 Kind regargs