Latest Windows 10 upgrade, 1803, breaks TE.COM about runcpm HOT 5 CLOSED

That part of the ui is very simple in TE:

switch(toupper(getchr()))
{
	case 'N'   : run = MenuNew(); break;
	case 'O'   : run = MenuOpen(); break;
	case 'S'   : run = MenuSave(); break;
	case 'A'   : run = MenuSaveAs(); break;
	case 'B'   : MenuAbout(); ++menu; break;
	case 'H'   : MenuHelp(); ++menu; break;
	case 'X'   : run = stay = MenuExit(); break;
	case K_ESC : run = 0; break;
	default    : ask = 0; break;
}

I think you should debug the input / status keyboard routines in RunCPM to see if there is something wrong related to the last Windows 10 update.

By the way, TE has been already improved in recent versions.

May be is worth for you to check the last version in my github repository

from runcpm.

Thanks Miguel, I will definitely do it.
Something strange is happening, I need to figure it out.
And I just tested a RunCPM .EXE I had compiled before upgrading my machine, and it seems to be working fine. Something is wrong with the newly generated executable.
It seems to be working fine on other OSes.

from runcpm.

Found the issue ... a call to _getch(), which is the "conin" BIOS call for CP/M, somehow returns zero.
So when I press "X", TE correctly shows "Confirm Y/N:" and waits for keypress, that keypress comes back \0, and it goes back to the menu.
It was happening so fast that I was not able to see it.
Now I am trying to figure out why the extra \0, so I can fix it.

from runcpm.

Check if _kbhit() returns true before you call _getch() when it returns '\0'. May be you get a clue if you do that. Good luck!

from runcpm.

_kbkit() was returning a valid waiting character for the \0 ... I have applied an ugly fix (workaround) for now. Will research more on it as I have time.
Closing for now.

from runcpm.