LabVIEW
VISA is generated INF that can't be installed in Win10
@uCore wrote:
Does National Instruments have an update or a solution for resolving this issue with Windows 10 signing that doesn't involve the two options suggested?
Unfortunately there is no solution for this that NI could do for you. Signing works by signing the final document (here inf file) to make sure it is authentic, unaltered and from the person the used certificate for the signing belongs to.
NI can't give you their certificate to sign your drivers for several reasons.
1) The certificate needs to be kept secure as once out in the wild anyone could sign any driver and claim it was from NI.
2) NI can't vouch for your drivers security and intend. You could create a driver that has not so honest intentions and NI does not want to be associated with such a driver by their certificate signature.
Microsofts decision means that you have to either disable driver signing (likely something that will at some point be simply impossible without hacks) or pay a certification authority to sign your driver for you.
If it makes you feel better, the same is true for MacOS X. Drivers without proper signature can't be installed there anymore.
There exists a solution. Buy a certificate from a trusted CA and sign your drivers with the private key for that certificate and require your users to trust you and install your certificate in their trust store. But don't complain if Microsoft decides to change the requirements again for Windows 11 at some point. Self certification may very much be a thing of the past in the future.
Or you can spend your energy in creating a LabVIEW binding to WinUSB or libusb. Both allow to access USB devices from user space without the need to have a device driver INF file that must be signed. It's certainly some work to do and if you decide to share your efforts with the community you may even get a few friendly reactions, but even more likely angry reactions like yours because feature XY doesn't work as the specific person wants!
For HID devices specifically you can also directly call into HID.DLL. There used to be many projects out there who included some form of HID.DLL binding, usually quite hacky and barely working, but they were out there. I don't see them as often nowadays but that might be also because I haven't talked with a HID device in ages directly.
The other option is to pressure Microsoft to not force driver signing. Good luck with that. They added that requirement to Windows to increase it’s security. Without this they can’t get the necessary certification that allows many governments and other public organizations to choose for Windows to install on their computers.
The problem is really at the oscilloscope manufacturer who decided to implement their own proprietary USB protocol that requires a specific device driver that their application of course knows how to communicate with. But NI can’t interface to every possible driver out there, that would be simply impossible. Just because your mouse is recognized by Windows doesn’t mean that VISA can talk with it either. This device seems not different. If they had chosen to implement an USB-TMC class device you could use VISA out of the box for it but they didn’t.
Possible reason could be:
- Make the development of their device as cheap as possible by using a specific firmware driver and Windows driver that came with the evaluation board for the USB chip they use instead of having to develop their own.
- They don’t like NI and other Test & Measurement manufacturers and absolutely want to live on their own little island that is only compatible with itself.
- They feel their hardware and software bundle is so superior that any user wanting to use anything else is nuts.
Even if you could register your device with VISA USB raw, your problems only just would start. Without a detailed protocol description of the USB protocol you could just as well try to talk to a toaster. And I’m not even talking about text commands to send, which your device may have or not on a higher level, but the bits and bytes, USB endpoints, interrupt transfers and more that you all need to setup properly and service regularly in order to be even able to start sending it commands which might be text but more likely bits and bytes too.
Does your oscilloscope manufacturer even have such a document for their proprietary protocol that they would be willing to send out on request?
@lutz1410 wrote:
I have the document and there are examples from other users who were still able to exchange the data with the oscilloscope with Labview under Windows 7
The real issue here is that the INF drivers cannot be installed by the NI VISA Wizard and the Meaurement and Automation Explorer can no longer recognize the oscilloscope without them.
Well it can be installed but it needs to be signed. Until Windows 10 1609 it was possible to just sign it with any self generated certificate, since then the certificate also needs to be traceable to an official root certification authority.
This means you would have to buy a certificate from some certification authority and then use the Windows SDK tools to sign your driver with that. This documentation describes the process for Windows 8 and later.
If it is only for your own PC, you can also use a self generated certificate and use it to sign the driver. You then need to install the certificate in the Trusted Root Certification Store on your Windows computer. This is necessary as Windows tries to trace the certificate used to sign your driver to a known and trusted root certificate and by installing your own certificate as such, it can be properly verified to be trustable (by virtue of the fact that only an administrator can change the Trusted Root Certification Store).
