DOS port keyboard support with WIDE=Y

[rexx-org]

There are many compiler warnings when building dos/pdckbd.c with WIDE=Y. Also function keys return incorrect values when a test program is run.
The problem is that key_table[] is specified as "short" and not "int" (as is specified in dosvga/pdckbd.c).
Changing:
static short key_table[] =
to
static int key_table[]=
fixes the warnings and runtime issues.

[Bill-Gray]

Hi Mark - As far as I know, you can't build a wide-character DOS version anyway. DOSVGA, yes. But DOS is a solidly 8-bit character platform.

I think I ran into this issue some time ago, when I heedlessly attempted a wide-character build with DOS. Unless we can figure out a way to display and read wide characters under DOS, I don't see much point in supporting WIDE=Y.

[rexx-org]

If you don't try and use wide characters then the code works fine; as long as the short is changed to int.
Maybe rather than compilation warnings and failed function key return vales when WIDE=Y is specified, a note in the dos/README.md file that states the limitation of wide character support. Or better a compiler warning/error when attempting WIDE=Y for dos?

[GitMensch]

Thank you for raising this issue and the discussion. I've changed the README to explicit say "use DOSVGA for WIDE=Y" and adjusted the port specific include file to raise an error "early" when this is set.

[Bill-Gray]

A nice and simple solution. I may just copy/paste Simon's solution into os2/pdcos2.h (the only other platform lacking wide-character support), just changing references to DOS to say OS/2.

Coincidentally, I noticed last night that eight AppVeyor builds were full of the warnings Mark mentioned, because they were builds of the DOS port with PDC_WIDE=Y. They now error out with the new message. Looking more carefully, it appears that they were intended to be wide-character builds of the DOSVGA port, but are actually builds of the DOS port. I'm not familiar with CMake, but it appears to me that AppVeyor did some redundant compiles of the DOS port and never actually got around to testing DOSVGA.

I think this will be easy to fix.