I'm trying to develop device independent library for barcode scanners, it has to be working in windows environment.

I've done some research in this field, afaik most of the solutions of this problem are depending on specific device VID&PID (RawInput @ filter by vid&pid string), in my situation this is inacceptable, because i'm trying to develop a device independent solution, which will be working with any USB-barcode scanner.

Actually this thing is quite challenging, for me atleast, here are exact requiriments. Also i can't ask user to hot-plug device (in that case i could've just detect plugged device and extract it vid/pid). Also i can't use VID&PID database of devices. In general i can't use vid&pid at all actually.

Also i can't in any way reprogramm barcode scanner, unless it's done from my programm (maybe i can send some barcodescanner-specific IOCTLs which will make it answer to me?).

Also i have seen commercial library (which is offcourse comes without any sources and any info about how it's implemented, but considering they have'd some word "Perfomance counter" in their changelogs, i guess they used solution in the link above), which implements this functionality, but it doesn't work in x64 systems. Probably either because of messy code or beacause it probably uses some kind of filter (mini) driver. It's crypted and i can't redistribute it.

My exact question is:
Is there any way to determine that this HID keyboard is in fact not a keyboard, but a barcode scanner? I've seen on Win 7 x64 that it connects as Barcode scanner, not keyboard (this was a system bug, or sort of).

Exactly what i'm doing now:

Reading input by RID_INPUTSINK.

Distinguishing all input by vid&pid of device

Putting all input to separate buffers and collecting barcodes from buffer when VK_ENTER shows on buffer.

What i'm currently going to do:

Read input by RID_INPUTSINK

Start timer for specific device and if next symbol is VK_ENTER - stop timer

If timer exceeds 50 ms limit - off it and drop all further device input.

If device will successfully read sequence of characters from first symbol to VK_ENTER - extract device VID&PID/handle and work with it in more convenient way (without timering).

I'm developng it on C++, pure WinAPI, it will be a DLL library, and got to work in Windows XP, Vista, 7, 8 on x32-86 and x32-64 architectures.

According to this document USB Barcode scanner have UsagePage 0x8C and Usage 0x02. Unfortunately i've failed using it as RAWINPUTDEVICE.dwUsage and RAWINPUTDEVICE.dwUsagePage. Probably because system install it's usb keyboard driver on top of it and in user mode it is indistinguishable from real usb keyboard. Probably those values are usable in kernelmode environment (one of the options is to develop hid filter driver).

1 Answer
1

More than a year ago, I implemented barcode reader support under even more adverse circumstances. It was for a reporting applicaton with association to logistical data in pure Java (cross platform rich client, primarily on Windows).
I found out the same you're saying about the keyboard driver, which prevents distinction of actual USB devices in user mode, at least at the first glance. There are more expensive devices with own drivers and advanced features, which would allow some sort of distinction.
All barcode readers I encountered in that environment were visible as keyboards and used to simply fill an SAP form field and hit the enter key, which is a common case. The termination may be configurable using 'magic barcodes' or another manufacturer specific method.

So the decision was against any JNI based, platform specific implementation.
Instead, I implemented also an interception-like approach (extended version of yours) by evaluating generic keyoard input within certain Swing/AWT forms using these criteria:

key stroke frequency determined by the first two chars (initially / after timeout)

jitter (frequency/rate change)

set of valid chars

terminating line break.

The input gets consumed by a buffer until the criteria for machine generated input aren't met, or the validation has been passed, where barcode listeners will be notified. In either situation, the input can be forwarded as if nothing else happened.

This has proven to be very accurate, since for a human, it's all but impossible to enter a valid sequence at the barcode reader's rate with (almost) zero jitter.

EDIT:

Just dug out the Java source; I can give you the code of an early revision of the implementation above as an example (no warranty, also consider to implement CR):