94 lines
3.1 KiB
HTML
94 lines
3.1 KiB
HTML
|
<HEAD>
|
||
|
|
<TITLE>Future Directions for DirectInput Keyboard Support</TITLE>
|
||
|
|
</HEAD>
|
||
|
|
<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#000000 VLINK=#808080 ALINK=#000000>
|
||
|
|
</BODY>
|
||
|
|
|
||
|
|
<H2>Future Directions for DirectInput Keyboard Support</H2>
|
||
|
|
|
||
|
|
<ADDRESS>
|
||
|
|
Raymond Chen<br>
|
||
|
|
Microsoft Corporation<br>
|
||
|
|
11 November 1997
|
||
|
|
</ADDRESS>
|
||
|
|
|
||
|
|
<h3>Abstract</h3>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Ideas for future versions of DirectInput keyboard support are presented.
|
||
|
|
|
||
|
|
<h3>Exclusive Keyboard Access</h3>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Currently, keyboards are supported only in passive (non-exclusive) mode.
|
||
|
|
Adding support for exclusive mode on the system keyboard
|
||
|
|
(<code>GUID_SysKeyboard</code>)
|
||
|
|
is extremely easy on Windows NT, and
|
||
|
|
a bit tricky on Windows 9x.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
On Windows NT, all that would need to be done is to have the
|
||
|
|
<code>CEm_LL_KbdHook</code> function return 1 without calling
|
||
|
|
<code>CallNexthookEx</code> in the situation where the keyboard
|
||
|
|
has been acquired exclusively. This will prevent Windows
|
||
|
|
applications (including the current application) from seeing
|
||
|
|
keyboard activity, while not preventing the secure attention
|
||
|
|
sequence (Ctrl+Alt+Del) from operating properly.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
For Windows 9x, the change would be similar, but more annoying.
|
||
|
|
The <code>DIKBD_Filter_Keyboard_Input</code>
|
||
|
|
function would return carry set rather than clear if the
|
||
|
|
keyboard is captured. Steal the basic idea from the
|
||
|
|
<code>dimouse.asm</code> file, which already does this for
|
||
|
|
mouse events. (I.e., handle the <code>DIKBD_Capture</code>
|
||
|
|
notification, set a flag in the instance structure,
|
||
|
|
and check the flag in the filter procedure.)
|
||
|
|
|
||
|
|
<p>
|
||
|
|
It's actually not quite that easy, because Windows 9x does not
|
||
|
|
have a security manager. The low-level keyboard filter procedure
|
||
|
|
would also need to track the virtual shift state and detect that
|
||
|
|
the user has typed Ctrl+Alt+Del. Under such conditions, the filter
|
||
|
|
would have to force-unacquire the device, then turn around and
|
||
|
|
re-inject the Ctrl+Alt+Del sequence (now with the filter disabled)
|
||
|
|
so the system can see it again.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Note also that
|
||
|
|
<code>CKbd_SetCooperativeLevel</code> would need to be changed
|
||
|
|
to understand which modes support exclusive access and which do not.
|
||
|
|
|
||
|
|
<h3>Disabling the Windows Logo Key</h3>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
This is a common request from game developers, because the Windows Logo Key
|
||
|
|
sits right next to two extremely popular game keys - Ctrl and Alt.
|
||
|
|
Accidentally pressing the Windows Logo key causes the Start Menu to open,
|
||
|
|
which in turn causes the application to lose focus and possible even lose
|
||
|
|
its display surfaces.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
This can be solved as a restricted (and much easier)
|
||
|
|
form of exclusive keyboard access. Again, on Windows NT,
|
||
|
|
we would merely check if the incoming key is
|
||
|
|
<code>VK_LWIN</code> or <code>VK_RWIN</code>; if so, then return 1
|
||
|
|
immediately without chaining.
|
||
|
|
On Windows 9x, the filter procedure would check for a scan code of
|
||
|
|
E0/5B or E0/5C (or their release counterparts E0/DB and E0/DC);
|
||
|
|
if so, convert the 5B or 5C (or DB or DC) to a harmless key like 00.
|
||
|
|
|
||
|
|
<h3>References</h3>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<cite>
|
||
|
|
<a href=http://www.microsoft.com/directx/resources/dx5ddk.htm>
|
||
|
|
DirectX 5.0 DDK</a>
|
||
|
|
</cite>, Microsoft Corporation.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<cite>
|
||
|
|
<a href=http://www.microsoft.com/directx/resources/dx5sdk.htm>
|
||
|
|
DirectX 5.0 SDK</a>
|
||
|
|
</cite>, Microsoft Corporation.
|