@dougbinks may be interested

Tested on current master (as of today) with 'events.c' demo on Windows 8.
The callback set from glfwSetCharModsCallback is called when ALT modifier is modified (as messaged via WM_SYSCHAR) but not when CTRL modified is pressed. Making it hard for an application to process shortcuts (e.g. CTRL+S) while relying on translated characters.

I have looked into it, surprising enough it appears that it is a bit of a pain to retrieve this information under Windows.

Adding this at the end of message handler for keys messages appears to fix it, albeit in a rather ugly way:

        case WM_KEYDOWN:
        case WM_SYSKEYDOWN:
        case WM_KEYUP:
        case WM_SYSKEYUP:
[...]
            if ((uMsg == WM_KEYDOWN || uMsg == WM_SYSKEYDOWN) && (mods & GLFW_MOD_CONTROL))
            {
                static BYTE keys[256] = { 0 };
                WCHAR buf[4];
                int buf_sz;
                int n;
                keys[VK_SHIFT] = (mods & GLFW_MOD_SHIFT) ? 0x80 : 0;
                buf_sz = ToUnicodeEx(wParam, scancode, keys, buf, 4, 0, NULL);
                for (n = 0; n < buf_sz; n++)
                    _glfwInputChar(window, buf[n], getKeyMods(), FALSE);
            }

            break;

As I understand it, DefWindowProc generates WM_CHAR / WM_SYSCHAR messages from WM_KEYDOWN / WM_SYSKEYDOWN messages, and code above replicated the effect for me. It looks a little dodgy but I haven't spotted a flaw with it yet.

It might fail on certain edge cases (I don't know them) but I am tempted to say that it can't be a regression since currently we get nothing under Windows when CTRL is held.

(With Microsoft IME active when holding is doesn't popup anyway so I typically get the Latin character in this case, which is desirable)