From: henshaw@emperor.gatech.edu (Andy Henshaw)
Newsgroups: comp.os.os2.advocacy
Subject: keystroke programming in OS/2 and NT
Date: 12 Nov 92 18:15:20 GMT
Originator: henshaw@emperor

Maybe this should be added to Brian Sturgill's "OS/2 vs NT" list:

In the December issue of the "Microsoft Systems Journal" there is
an article by Jeffrey Richter titled "Simulating Keyboard Input
Between Programs Requires a (Key)Stroke of Genius."  In the
article, Richter describes how a naive attempt to send keystrokes
between applications by posting WM_CHAR messages would not be
sufficient.  He then goes on to describe a couple of workable
methods - one using the PostVirtualKeyEvent function supplied
with Windows for Pens and another that uses Journal Playback hooks.
The Journal Playback hook is the one he seems to prefer and he
describes this method in detail.

This is where it starts getting interesting.

There is a sidebar describing "Keystroke processing in Windows NT."
It describes how the PostMessage is better under NT because of
separate, expandable input queues.  But it explains that this
is still not a good solution because of GetFocus () problems.

Then, the option of using PostVirtualKeyEvent () is dismissed because
the Pen Windows technology hasn't been ported to NT generally because
Microsoft doesn't yet see the need for pen input on NT class machines.
And his version of PostVirtualKeyEvent (written for those without
access to Pen Windows) won't work because of the use of assembly language
and that the keyboard drivers for NT are completely different than those
for 16-bit Windows.

The final option (JournalPlayback) also won't work if NT is running
strict security because the hook is a system-wide hook and NT won't
allow it.

The whole sidebar discusses the problem without recommending a solution
for NT, although I would imagine that there is one.  


Really interesting stuff here !!!

The end of the article I will just quote from:

 "...Seems pretty complex doesn't it?  Wouldn't it be great if there
  were  some way to simplify all of this?  Maybe a way to cut down
  on the number of keystroke-related window messages?  If you're
  wondering about this, you're not alone.  Microsoft realized long
  ago that the keystroke processing was far more complex than it
  had to be and fixed it.  The fix is in an operating system called
  OS/2 {rtm}.
    In OS/2 Presentation Manager {rtm} (PM), there is only one
  keystroke message, WM_CHAR.  There are no WM_(SYS)KEYUP, 
  WM_(SYS)KEYDOWN, or WM_(SYS)DEADCHAR messages.  Every message
  has two parameters associated with it just like Windows, but in
  PM both means, of course, that every message in PM can have 16
  bits more of information associated with it.
    Every time a PM window procedure receives a WM_CHAR message,
  the procedure has access to the scan code, virtual-key code, and
  ASCII key code corresponding to the pressed/released key.  Because
  PM converts the virtual-key code to the ASCII code equivalent,
  there is no need for a function like TranslateMessage.  To make
  things even easier, the last 16 bits of WM_CHAR's first parameter
  contains a more useful set of flags as compared to the lParam in
  Windows keystroke messages.  Personally, I think that the PM
  approach to keystroke message processing is superior.  
  Unfortunately, even though the Win32{tm} API uses 32-bit parameters
  for all its messages, Microsoft must still stick to the original
                        ------------------------------------------        
  paradigm used in Windows.  If Microsoft were to incorporate the
  ------------------------
  PM paradigm into Windows, all Windows-based applications that 
  performed keystroke processing would break.  Oh well!"

(underline mine)
{rtm}  registered trademark
{tm}   trademark

Andrew Henshaw
School of Electrical Engineering
Georgia Institute of Technology
henshaw@cerl.gatech.edu