Note that with Windows 10, not even that .INF is required. When the scanner is connected, Windows 10 automatically starts using USBSER.SYS, assigns a COM port number, etc., just like it automatically assigns a drive letter and gives access to the scanner's SD card without an .INF.
A very quick and simple search of this forum proves otherwise. Either that, or many (if not most) Whistler scanner owners, myself included, are either liars and/or incompetent.
The drive letter has to do with the USB Mass Storage Device, which generally does work on its own. The software generally has decent luck getting to the SD card, though many people report 3 failures before it works right. However, it's a whole different story when it needs to access the scanner memory to perform a firmware update.
I've covered much of this before, but Radio Reference censored the thread. Perhaps they might bring it back. If there is interest, I can try to find my original posts in that thread. It's also been covered in other threads.
Using the internet to search, also can be useful:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn707976(v=vs.85).aspx
What you described would probably work (and it might work
already if people DO NOT have the actual Whister driver on their computer) if the device ID was set correctly for a class code and subclass code of 2. That's what's listed in the compatibleIDs, but the deviceID isn't.
If you want to load Usbser.sys automatically, set the class code to 02 and subclass code to 02 in the
Device Descriptor. For more information, see USB communications device class (or USB CDC) Specification found on the
USB DWG website. With this approach, you are not required to distribute INF files for your device because the system uses Usbser.inf.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff539283(v=vs.85).aspx
For example, the idVendor and idProduct fields specify vendor and product identifiers, respectively. Windows uses those field values to construct a hardware ID for the device.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff539280(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538820(v=vs.85).aspx
More internet search results:
- You don't need to sign usbser.sys (KMCS) but you still need to sign your .inf, because the matching of usbser.sys to your Hardware ID or Compatible ID is not trivial and it's your responsibility, so you should be signed on it.
- You don't have to go through WHQL certificate on Windows Vista and higher. A code signing certificate from a known CA will suffice. This will raise a question of "Do you want to trust this publisher?". You can work around this by first adding yourself to the TrustedPublishers (see this question). (WHQL still has its benefits, e.g. you wouldn't have the above warning prompt.)
Can .inf file reference a built-in driver such that it won't give warning during installation? - Stack Overflow
Yes, the final version of Windows 8 does require all INF files to be signed, but you do not need to submit your drivers to the WHQL.
certificate - In Windows 8, will third-party INF driver files require a signature? - Stack Overflow
(Marcotor pay attention to the above ^^^ quoted information...)
And this great article, which has specific information regarding USB to Serial drivers and USBSER.sys (why I chose it).
Practical Windows Code and Driver Signing
A driver package consists of a single
INF file and the files that it references.
Blaming this on Windows cracks me up. Half of this forum must be unsubstantiated mumbling.
If your driver only uses
WinUSB or usbser.sys, all you need to worry about is getting your driver package installed, as described in the
Installing a driver package section.
The kernel modules you are using have already been signed by Microsoft and you will have no trouble getting them loaded into the kernel after the driver package is installed.
Of course, in the Whistler driver, they try to pass off some signed file mchpcdc.cat (see lines 106 and 17) as their own (a file that is found in Windows). But I doubt it would work with their driver package. No wonder Windows sends up warning flags.
See line 18 of the driver: DriverVer=11/15/2007,5.1.2600.0
Perhaps General Research of Electronics or whoever this was taken/bought from will help.
It's shocking to me that people don't even open up the driver as a text file and look on their own.
I would be happy to help resolve these problems, because I think it's
absolutely ridiculous that so many people struggle with this.
There is obviously poor understanding of these issues. Perhaps posting quotes and links from third party sources might allow us to progress instead nonsense directed at me. I think I have sufficiently led the horse to water.
and move on. Though could it be fixed .. sure, but why when it is not that hard and does work except for a select few.