Bill Gray

Been distracted by day-job activity, but just got a few minutes to dig into this. I don't have a fix quite yet, but thought I'd write down what I found...

Haven't used that. I expect the compiler in MSYS2 would create the same code as MinGW run from Linux. That is to say, I _think_ it's basically the same compiler,...

Compiling the test code with gcc from MSYS2 also got wrong, though more consistent, results. (Should note that MSYS2 is using gcc-12.2.0; on my Xubuntu 20.04 box, MinGW has gcc-9.3.)...

> :-( So you see no option to bit-fiddle the result back to the "expected" one? None, since the actual information has been lost (some key hits map to the...

Okay, I've found and fixed at least _a_ bug, and I rather suspect it is _the_ bug. See commit e54d03fc80786d02c6f55d2b7689f4d2011db0c1 . Without this, `UNICODE` would only get #defined if you...

Compile with those flags, and you should get Unicode results from `wget_wch()`. To get results for your current code page, we'd then convert the Unicode result using `WideCharToMultiByte`. Or, probably...

I am reasonably sure that commit e86d9c35683cfd0 fixed this. WinCon compiles with UTF8=Y will get correct results from `wget_wch()`; for those without, `getch()` will return code page appropriate results for...

Closing this as completed. Note that commit e86d9c35683cfd06a25ad05974 implements the bit described above of casting `KEV.uChar.AsciiChar` to type `unsigned char`. That was the final piece of that puzzle.

Will give this a try. [I have a bit of code to test key speed](https://www.projectpluto.com/temp/keytest.c) that fell out of issue #197. As noted therein, a recent change _really_ boosted the...

Can't say there was any performance improvement. (I'd have been surprised had there been one; the compilers probably optimize things to result in roughly what you did with the 'early...