I discovered this while working on #4586. The code in question was
updating `*puKey` and then trying to dereference the array on the basis
of its new value, which (a) would give the wrong result, and (b) could
be reading off the end of the array (although not crashing it seems),
e.g. for `"` -> `VK_QUOTE`, which has a value of `0xDE`.
I am guessing that the reason we have not seen any bug reports on this
is that the keystroke handler falls back to an alternate code path, so
in the vast majority of cases, keyboards would continue to work
correctly. Furthermore, the test was just for truthiness of the `BOOL`
so probably at least 50% of the time we'd have been okay anyway. Or
something. Anyway, I reckon this is better.
[Windows] More tidyup and robustness for metro app support - debug cleanup and serialization of input (not quite finished)
[windows] Refactor serialized input code when used with key event thread model
[windows] Add consistent precompiled headers for other projects
[windows] Merge console window test into metro support
[Windows] Tidy up work and identify additional TODOs for metro-style app support
[Windows] Ensure error case falls through to default hook processing for console windows
[Windows] Refactor shared memory into memory mapped file so we can cross 32-64 bit boundary
[Windows] Tweaks to C++ security calls and parameters
[Windows] Start refactor of SerialKeyEvent* classes
[Windows] Rename to SerialKeyEventServer (refactoring)
[Windows] Complete refactoring of SerialKeyEventClient class
[Windows] Further encapsulation and cleanup with 'interfaces' to reduce header pollution
[Windows] Complete serialization fix with move of modifier state management from client thread to server thread to guarantee consistency
[Windows] Replace atom-based keyboard switching with memory mapped file indexed to avoid security constraints
[Windows] Fixup Left Alt+Shift interaction with serializer
[Windows] Use Windows 8.1 SDK for test
