Modern Windows Input API / User Interaction API

Question

There's a wide variety of User Interaction APIs / technologies, available in Windows 8.1:

• High-level GUI frameworks (Windows Forms, WPF and many other third-party frameworks)
• Direct Manipulation – Probably high-level too.
• Pointer Input Messages and Notifications (MSDN link) – Interesting, but where is the keybord API analogue?
• DirectInput / XInput – Marked as legacy.
• Raw Input – Marked as legacy.
• WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_KEYDOWN, etc. messages – Marked as legacy.
• Other, listed on this MSDN page

Can anyone give me a brief overview of these APIs and reveal the following aspects (for each of them):

• Is this API based on another underlying API or implemented in the core?
• With what devices this API can interact?
• Any exclusive features, not implemented in other APIs?
• Performance / overhead considerations: How fast is it (in comparison with others)?

So I'm looking for native up-to-date low-level full-featured input API, which won't become obsolete in the upcoming Windows 10, or the mixture of those (described above) APIs, closest to this needs.

Can anyone make some kind of comparison table?

Answer 1

The Pointer Input Messages and Notifications seem to be an extension of the well known message cycle to support multitouch devices. You could easily integrate that with standard keyboard messages for a full featured API. As Retired Ninja pointed out, the messaging API is likely to outlast most 'modern' APIs.

I would avoid any fancy new technique that diverges from the standard WinAPI, because these paradigms seem to come and go. Making the low level input handler thin, loose coupled and standardized will help your program stay maintainable.

The thing about Windows messaging API is it gets extended every time a new device or feature is introduced, and that's about as coherent as it gets. Any higher level interface is likely to be incomplete at first, then obsolete, and probably based on WinAPI calls anyway.

I have given up making the WndProc look nice, with nested switches, multiple if...else etc.. Now I keep it in its own source file, where it can do its dirty work of passing values to outside code.