Terminal problems

[Gisle Vanem]

I'm using TCC 30.00.22 under Windows Conhost w/o the Legacy Console. on Win-10 (19045.3324)
My issue is that after running some programs that messes up the console settings (or prints some
illegal ESC-sequence?) to the extent that e.g. up/down arrow key no longer works.
Even an echo <F1> simply prints OP and pressing <F7> shows [18~, pressing Ins shows [12~ etc.
What's going on here?

My only fix is to exit and restart the TCC instance. Or is there another fix for this annoying problem?

 

[Gisle Vanem]

I've experimenting and running this reset-term.bat brings back the up/down arrow-keys etc.

@echo off
echo default all:                 > %TEMP\reset-term.mak
echo %@char[9]@echo 'reset-term' >> %TEMP\reset-term.mak
gnumake.exe -f %TEMP\reset-term.mak

But I fail to understand why.

BTW, one program that messes up the console is Wget2.

 

[vefatica]

When it happens, this might fix it.

echo %@winapi[kernel32.dll,SetConsoleMode,%@fileopen[con:,r],487]

If that does work, then you have run into the same issue discussed in this thread.

 

[Gisle Vanem]

Thank Vince, I'll try this.

 

[Gisle Vanem]

Trying it, I find the pesky Quick-Edit mode gets enabled. AFAICS:
487 = 0x1E7 ==
ENABLE_PROCESSED_INPUT | ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT | ENABLE_AUTO_POSITION |
ENABLE_INSERT_MODE | ENABLE_QUICK_EDIT_MODE | ENABLE_EXTENDED_FLAGS

Right?

So dropping the ENABLE_QUICK_EDIT_MODE bit, I now use:
echo %@winapi[kernel32.dll,SetConsoleMode,%@fileopen[con:,r],0x1A7]

instead.

BTW. how do I do the reverse? This doesn't work:

set mode=0
echo %@winapi[kernel32.dll,GetConsoleMode,%@fileopen[con:,r],%mode]
echo mode: %mode

 

[vefatica]

If you use echo %@winapi[kernel32.dll,GetConsoleMode,%@fileopen[con:,r],buffer] the current mode will be put in the buffer and then output. But TCC has no way of knowing what it is, and will treat the buffer as a string. Here it looks like this:

v:\> echo %@winapi[kernel32.dll,GetConsoleMode,%@fileopen[con:,r],buffer]
ǧ

So turn it into a hex number like this:

v:\> echo %@eval[%@unicode[%@winapi[kernel32.dll,GetConsoleMode,%@fileopen[con:,r],buffer]]=h]
1E7

I have this utility (below). If it will be of value, I'll make it available.

v:\> conmode

Console input mode flags (0x1E7)

    ENABLE_PROCESSED_INPUT (0x1)
    ENABLE_LINE_INPUT (0x2)
    ENABLE_ECHO_INPUT (0x4)
    ENABLE_INSERT_MODE (0x20)
    ENABLE_QUICK_EDIT_MODE (0x40)
    ENABLE_EXTENDED_FLAGS (0x80)
    ENABLE_AUTO_POSITION (0x100)

Console output mode flags (0x7)

    ENABLE_PROCESSED_OUTPUT (0x1)
    ENABLE_WRAP_AT_EOL_OUTPUT (0x2)
    ENABLE_VIRTUAL_TERMINAL_PROCESSING (0x4)

 

[Charles Dye]

You could put your fix in a plugin, apply it every time the prompt is displayed.

 

[vefatica]

You could put your fix in a plugin, apply it every time the prompt is displayed.

Yes, but I don't have a template for single-purpose plugins (you must @Charles Dye, eh?). And to get it done at every prompt a plugin would need to do that in a keyhandler or a plugin POST_EXEC/PRE_INPUT. I did this (below, actually I use NOOP) after my first bad experience with some Cygwin apps. It's surely easy and so unobtrusive that I forgot I had done it.

v:\> alias post_exec
echo %@winapi[kernel32.dll,SetConsoleMode,%@fileopen[con:,r],487] > NUL

And that raises a question. I said "r" in @FILEOPEN figuring that @FILEOPEN wound give a "CONIN$" handle (vs. a "CONOUT$" handle with "w"). But "w" works equally well. So I wonder ... what does @FILEOPEN[con:,*] actually give a handle to?

I could easily add a SET option to my CONMODE.EXE and make it available. It could be used in POST_EXEC/PRE_INPUT. At the moment, CONMODE.EXE works like this.

v:\> conmode /?

Show console mode flags

Usage: CONMODE [option], default: show current input and output mode flags

Options:

  /I - show only current input mode flags
  /O - show only current output mode flags
  /A - show all possible mode flags

I could easily add /SI and /SO options.

 

[vefatica]

Aha! It's in the help.

@FILEOPEN TCC internal variable function
To read from standard input, use CON: for the filename.

That explains why @WINAPI works for the purpose at hand.

 

[Charles Dye]

Yes, but I don't have a template for single-purpose plugins (you must @Charles Dye, eh?).

Basically it's just the demo plugin from the SDK, with some added stuff like a help system and a VERSIONINFO resource.

v:\> alias post_exec
echo %@winapi[kernel32.dll,SetConsoleMode,%@fileopen[con:,r],487] > NUL

You're opening a console handle at every prompt? Do they get closed somewhere?

 

[vefatica]

You're opening a console handle at every prompt? Do they get closed somewhere?

I asked myself the same thing last night.

The alias doesn't close them. But checking with HANDLE64.EXE (SysInternals), even after TCC has been running for days, I don't see handles piling up.

What do you think?

 

[Charles Dye]

I asked myself the same thing last night.

The alias doesn't close them. But checking with HANDLE64.EXE (SysInternals), even after TCC has been running for days, I don't see handles piling up.

What do you think?

C:\>echo %@fileopen[con:,r]
80

C:\>echo %@fileopen[con:,r]
80

C:\>echo %@fileopen[con:,r]
80

C:\>echo %@fileopen[con:,r]
80

C:\>echo %@fileopen[con:,r]
80

C:\>echo %@fileclose[80]
TCC: (Sys) Access is denied.
 "%@fileclose[80]"

C:\>

I guess @FILEOPEN is not opening a new handle, just returning a standard handle. So never mind.

 

[vefatica]

I don't know for sure, but @FILEOPEN may be returning GetStdHandle(STD_INPUT_HANDLE). There may be only one of them (though it may be changed by redirection).

My CONMODE.EXE uses handles to "CONIN$" and "CONOUT$" and closes them.

I'm redesigning CONMODE. I have all the work_horse functions in place but still have to write main()'s parser. At the moment I have this (below). Comments and suggestions will be welcomed.

Show/set console mode flags

Usage: CONMODE action [action ...]

Actions (done in order of appearance)

  /I - show the current input mode flags
  /O - show the current output mode flags
  /L - list values and names of all available mode flags
  /A flag_name - add named flag to current mode
  /X flag_name - remove named flag from current mode
     flag_name (case insensitive) will determine input/output
  /SI mode - set input mode
  /SO mode - set output mode
      mode - hex with or without "0x"

 

[ohenryx]

Sorry to resurrect an old thread, but I have a similar problem, only not with conhost.exe but with Windows Terminal.

Certain programs mess up the terminal window when run. One easy example is the "vim.exe" that is distributed as part of the vim/gvim 9.1 package. The vim.exe distributed with Cygwin does not exhibit the same problem. I have windows terminal set to launch with a size of 120 columns and 30 rows, and the internal "cls" (from TCC and CMD) only clear part of the screen, not touching the bottom few rows. To be clear (no pun intended), "Cls" works correctly before running Vim, but not after. "Clear.exe" from Cygwin, or from Git, will clear the entire window, but the internal cls (TCC and CMD) still gets it wrong.

I am assuming that all of the above comments are directly related to Conhost, and thus do not apply to Windows Terminal?

ON EDIT: Never mind, I fixed it. In the mswin.vim file, I changed:

set lines=26
set columns=92

to read:

if has("gui")
set lines=26
set columns=92
endif