Regression on EOF on stdin

[andrewbird]

I have a test on Dosemu2 test suite that does this

1/ Creates a serial port that responds "hello world\n\x1a" when read from
2/ Starts a DOS process and runs a batch file that does "type com1"
3/ Checks that "hello world" is printed to the screen.

In ke2042 (FreeDOS 1.2) kernel this worked fine.
In ke2043 (FreeDOS 1.3) kernel and all the way up to present "type com1" doesn't return unless the user types Ctrl-Z in the dos window

I've git bisected back to the bad commit which is:

19a6dc1 is the first bad commit

commit 19a6dc1ba40c91badb8a5372bffffff902bb399e
Author: lpproj <lpproj@gmail.com>
Date:   Fri Dec 27 17:41:51 2019 +0900

    Fix func 0Bh (Get STDIN Status) always returns AL=FFh with some alternative CON drivers:
    
    * qwikansi.sys (simtelnet: simtelnet/msdos/screen/qwikansi.zip
    * most of Japanese input methods (Microsoft MS-IME, ATOK, WXP/WX2/WX3)

 kernel/chario.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

As a test I've reverted that commit on the current git HEAD and the problem is resolved. The original discussion at dosemu2 where the problem was first noticed was here dosemu2/dosemu2#2776

[andrewbird]

kernel/kernel/chario.c

Lines 97 to 103 in 8fe2a2e

	STATIC int Busy(struct dhdr FAR **pdev)
	{
	CharCmd(pdev, C_NDREAD);
	if (CharReqHdr.r_status & S_ERROR)
	CharCmd(pdev, C_ISTAT);
	return CharReqHdr.r_status & S_BUSY;
	}

So it seems that line 101 is never run. i.e. condition from serial driver is never S_ERROR (checked by patching FDPP and running under gdb). Interesting that https://fd.lod.bz/rbil/interrup/dos_kernel/210b.html#2604 mentions that console drivers for DBCS can return 0xff for the partially formed double byte chars, so this is probably what the original patch was trying to fix. Anyway this is beyond my knowledge so I'll bow out now and leave for others to fix.