Skip to main content



What this page covers

This page will give the developer an idea of the Windows Touch interface. This documentation is not intended as a recommendation for use. It is presented so the software architect can make an informed decision about using this instead of Wacom's Multi-Touch or Wintab APIs.

Target platforms

Windows operating systems: Windows 7, Windows 8 and following.

Programming framework, SDK, languages

Applications that use Windows Native Touch can be written in any programming language that supports the Windows Touch API. Of particular focus here is C/C++ development using Win32. This has been included since Windows 7 and expanded with Windows 8. Windows 10 supports all three interfaces.

Windows Touch Architecture Overview


The Win32 API is designed for use with the Windows message routing mechanism. Each application has one or more message loops and at least one windows procedure. The Multi-touch Hardware provides data to Windows kernel. The Touch SDK implementation can be used to react to messages in the application window. At a high-level, it looks like this:

Windows (not just Windows 7) routes input data via messages to applications. For example, keyboard events are sent to the application that currently has focus. This same model is available for touch events, gesture events, or pointer events depending on the version of Windows and what the application has registered to receive.

Basic programming model

The image below is particularly applicable to the WM_TOUCH implementation. The Windows kernel notifies our application of touch events. These can be handled directly in the application. Alternatively, the events can passed directly to the Manipulation Processor, or to the Inertia Processor and then the Manipulation Processor. Acquired data can then be processed in the application space for use in drawing or signature capture (two common examples).

The WM_GESTURE model does not respond individually every single touch event message. Instead, it has it's own API to respond to gestures as recognized by Windows itself. There is a well-defined set of recognized gestures (Pan / Zoom / Rotate) that are uniformly handled by Windows.

Extended programming model

The following image reflects a significant change in thinking that was implemented with Windows 8. Instead of individual categories of events for Mouse, Touch and Pen, the messages have been unified into a single pointer input API.

The chart below may be useful for deciding which of the two "bare-metal" interfaces that Microsoft supplies.

Exclusivity of gestures and raw dataWM_TOUCH and WM_GESTURE are exclusive.WM_POINTER can be used in conjunction with TIE.
Input delaysWM_TOUCH has palm rejection delays by default.WM_POINTER has no input delays.
Multiple Window SupportWM_TOUCH can only be delivered to one window. Contacts in other windows are dropped after the initial target window is determined.WM_POINTER messages can be delivered to multiple windowns simultaneously. Capture APIs provide additional functionality here as well.
Frame vs. non-frameWM_TOUCH is frame-based.WM_POINTER is non-frame-based by default, but developers can consume frames if they choose.
Rich dataWM_TOUCH contains basic contact geometry (height and width only).WM_POINTER supports more detailed contact geometry data as well as other richer information in the association structs such as TOUCH_INFO.
Tying touch to mouse dataWM_TOUCH always promotes the primary contact to mouse.WM_POINTER does no mouse promotion by default. WM_POINTER has a separate method for controlling activation.
Capture supportWM_TOUCH supports only its implicit capture model on a single window.WM_POINTER provides a capture API for controlling how capture works for contacts and windows.
Activation supportWM_TOUCH relies on the mouse messages it promotes to control activation.WM_POINTER provides an activation API to control how activation works for a window.
Pen and other pointing device inputWM_TOUCH does not include pen input.WM_POINTER can carry any pointing device's input.

Each application can choose which method to implement. Using the WM_POINTER approach does not support Windows 7.

See Also

Overview – Introduction to Windows Native Touch

Reference – Contains links to Windows developer documentation

FAQs – Answers to questions about getting started

Where To Get Help

If you have programming questions about using the Microsoft Touch APIs with Wacom products in particular, please visit Wacom support:

You may also visit Microsoft support for detailed information on the Microsoft Touch APIs from the Microsoft developer community and experts.