responded to it.
i think the get_key should be modified as well. else the key will be skipped.

> you can inject and retrieve 0000 through the keyboard buffer
> using INT16/AH=5 and it comes through with INT16/AH=1

I don't think this is done anywhere, so it would be much
easier to just remove the 0000s in add_key (?)

@Qbix: I've updated the patch to fix get_key() as well.

@wd:
A test case can be made quickly in DEBUG:

-a
13A7:0100 mov ah,5
13A7:0102 xor cx,cx
13A7:0104 int16
13A7:0106 mov ah,1
13A7:0108 int16
13A7:010A int3
13A7:010B
-g

AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=13A7 ES=13A7 SS=13A7 CS=13A7 IP=010A NV UP EI NG NZ AC PO NC
13A7:010A CC INT 3
-q

On CVS this runs with ZF=1. Changing add_key() to drop 0 would thus break INT16/AH=5; they should probably be dropped upstream in the input code, as Ctrl+Tab doesn't put anything in the buffer on a real system, but that code looks complex enough to warrant a separate patch.

As a side note, I just noticed that backspace doesn't work when running debug.exe under DOSBox CVS. I don't know what causes that, though.

> A test case can be made quickly in DEBUG

Of course, but the question is if some game/program
really DOES this. And i don't see any reason why this
should happen.

In dosbox it happens only when an entry is missing and
the key combination can be entered and is passed through
by the int9 handler. This actually happens for CTRL-Tab
which has a none-entry in scan_to_scanascii.
This entry should be 0x9400 (why do you assume it has
none?) so this value is entered into the dos key buffer,
but it is not returned by int16/ah=0/1 as it is only
present on extended keyboards (this functionality is
missing in dosbox, extended keys are identified by
the extended-prefix 0xe0, which simplifies things
pretty much).

So imho for a correct fix, the scan_to_scanascii table
should be updated where needed, zero-codes ignored in
add_key and int16 enhanced to handle extended keyboard
keys correctly (i personally would omit the last thing,
the rest should do it for now?).

I don't assume. I ran a test in debug.exe on a bare DOS installation, typed Ctrl+Tab, and had nothing come through INT16. And yes, the keyboard lockup can also be resolved by blocking zeroes at add_key(), but as long as INT16/AH=5/CX=0 still goes through that function such a change would not be a complete fix. If someone's going to go through and fix the scanascii tables, why not modify the code that uses it to drop the unmapped combinations above add_key() and have a 100% correct patch?

> typed Ctrl+Tab, and had nothing come through INT16.

That's right, but there is a scancode added to the keyboard buffer,
which is not passed to the dos program through int16/ah=0 as
it is an enhanced keyboard key combination (int16/ah=10 should
get it).

See attachment, should return correct (in terms of msdos6.x)
values for the bios keyboard buffer as well as int16/ah=0/1
(i think int16/ah=10/11 as well, but not sure).
Feel free to modify it, i'm still not sure if just removing the
0's before they are added to the keyboard buffer would be
even better than this as it would have much less possible
side effects (int16 being used by dosbox itself).