TouchCursor

Something that surprised me when I started getting user feedback about TouchCursor was how many people use virtual machines, such as VirtualPC or VMware: Judging by the small, self-selecting sample of users who have contacted me, it looks like everyone uses them.

This prompted me to focus on a problem with the earlier versions of TouchCursor, which failed to send keystrokes to the VMs. There was a workaround – Install it on the guest OS – but that was a pain, and what if your guest OS wasn’t Windows? Then you were out of luck.

There turned out to be two issues causing the problem with the virtual machines:

Firstly, a straightforward bug in TouchCursor: The VMs were processing hardware scan codes, while TouchCursor was only dealing with Windows virtual key codes. This seems obvious with hindsight – The guest OS will be sent hardware-like events with the minimum of host OS interference. Fortunately this was easy to address, using the Win32 MapVirtualKey() function.

The second problem was caused by the order in which Windows hook functions get called when a keyboard event occurs: The most recently added hook gets called first. The VMs installed hook functions after TouchCursor, so they received keyboard events that it hadn’t modified. The current version of TouchCursor takes steps to stay at the front of the chain, so it continues to get the keyboard events first. [1]

Conceptually, TouchCursor is a modification to the keyboard. Your fingers get used to where the keys are and if they’re not always where you expect them, the result is disastrous. I am happy to say that the recent fixes have brought TouchCursor a step closer to behaving like part of the hardware.

Notes:

[1] VMware’s new “enhanced virtual keyboard” feature seems to step outside the hook system altogether, causing the original problem to reappear. Fortunately this can be addressed by disabling this option in the VMware settings and TouchCursor then works as it should.