LabVIEW
VISA is generated INF that can't be installed in Win10
Nobody blames Microsoft just as you can’t blame NI for the fact that enhanced security measures in modern OS’ make their 25 years ago developed VISA USB RAW access a pain in your ass for you. In order to get the necessary certifications that allow governments and universities around the world to even install Windows on their machines, they had to ramp up the security model of their OS.
If you really want someone blamed you should look at the oscilloscope manufacturer, for choosing a proprietary USB communication protocol to communicate with their T&M device instead of USB TMC, which exists about as long as the VISA USB RAW interface.
When developing a proprietary USB protocol device you also should provide a documented user space DLL interface to the device driver which can be interfaced with according DLL interfaces such as the Call Library Node in LabVIEW. They thought to be smart and use VISA USB RAW, which at that time may have looked indeed very promising.
- Single driver development for supporting LabVIEW on Windows, Mac and Linux.
- Just publish the protocol documentation and let the community do that development work.
- As it’s a community project it’s their task to do maintenance.
- etc.
Then came the reality that requires device drivers nowadays to be signed. NI can’t sign them for you as that is against the whole idea of having to sign a binary executable file to proof it was created by the person or entity who signed it.
Yes the INF file is not really a binary but it's technically a device driver nevertheless since it claims a hardware resource.
“But the oscilloscope software still can communicate with the device!” That’s because it uses its own device driver that is of course properly signed. And LabVIEW could use that too:
+ if the manufacturer had documented the user space DLL interface to it
+ if someone would have developed a VI library using Call Library Nodes to interface to that DLL.
The entire USB driver stack is different for these two approaches. The only common thing between them on the PC side is the actual USB connector and controller chip itself.
And as I said several times too, you need to sign the driver (INF file) in order to be able to install it. VISA (and LabVIEW) can't see hardware for which the according driver has not been installed in Windows. And Windows won't install a driver that is not signed. And no VISA can NOT interface to the proprietary driver that the software from the manufacturer uses as it has absolutely no idea about the software interface that driver provides.
It's not NI that goes this way to recognize a device. It is Microsoft Windows that does it. In order for a device driver to be installable in Windows, there needs to be an INF file that describes the Manufacturer and Device IDs of the device and which device drivers it should use. VISA installs its own USB RAW device drivers which are indeed signed, otherwise Windows would never let the NI installer install those device drivers, but that is only the protocol filter handler that does the translation between the USB low level OS driver and NI VISA.
Your INF file is a device driver too as far as Windows is concerned, as it specifies that any device with a specific VID and PID should be installed as NI VISA device and should be connected with the VISA provided filter device driver. The fact that the VISA filter driver is signed and installed does not preclude the according INF file from having to be signed too, since it does alter the OS device driver stack to connect some specific hardware with some specific device driver, altering the kernel environment of Windows. NI did not decide that device drivers need to be signed for modern Windows versions. At the time they developed the VISA USB RAW method, nobody was even considering that device driver signing ever will be a possibility, let alone be an unavoidable fact of life. If they had known that this will be required at some point, they would for sure have abandoned the idea of implementing VISA USB RAW right at that point!
That's the reality and you can jump high and low and claim that NI should make it work differently but they can't and won't! If they will do anything at all about it, it is to remove the USB RAW capability in the near future from VISA, since it simply has gotten unsupportable with modern OS developments.
If you want your VISA USB RAW driver to work without having to sign it, you need to stay with Windows 7. It is as simple as that. It's the increased security of Windows 8 and 10 that makes this required, and there is simply nothing NI could do about it to make it go away for you.
@lutz1410 wrote:
There is the NI VISA Wizzard, instead of referring to cumbersome outdated descriptions, why doesn't the Wizzard do this work, you could take a test certificate for personal use or refer to one that you have ordered, just as an idea, why does the Wizzard exist?
You already answered that question yourself. By the time the wizard would be released with these methods, they would be outdated and not work anymore!
When the wizard was originally released, these things all were not an issue, since drivers couldn't even be signed even if you wanted to. Later they could be signed but it was not required. Then they needed to be signed but the tools were proprietary. They were available for download through installing Windows SDKs and such, but NI can't just take Microsoft software and add them at will to their own products. Every single file and executable they want to use in such a way needs a proper license agreement with Microsoft, where umpteen lawyers need to have their piss over it, and by the time everything is finally agreed and signed, the tool is already outdated or even obsoleted.
Even if you created such a tool, and made it available on your own servers together with the according executables from Microsoft without a proper license agreement with Microsoft, you are in fact violating Microsoft copyright. It's not likely that Microsoft would care or even get to know about it in your case, but NI does not have that luxury of being under the radar of Microsoft lawyers. And to make matters even more interesting, there are jurisdictions such as in Germany, where any lawyer can send out a letter to anyone they feel is violating copyright or trademark and similar and request them to pay lots of money to them for their trouble to search for such violations and write an invoice and send it to them. Microsoft would not even get anything in these cases, despite the lawyer claiming to work in the interest of Microsoft.
Did you add the self signed certificate to your Windows certificate store?
Simply signing a device driver is not enough, Windows needs to be able to verify the chain of trust to a known root certificate. By installing your own certificate in the certificate store you make it your own personal root certificate.
But that is soon not enough. Microsoft wants all device drivers to need to be counter signed by their DevCenter. That means you will have to first sign it with a real certificate and not just a normal one but an Extended Validation certificate that costs easily double of a normal one, run the entire driver through their driver test suite and then submit the signed driver with the test report to them after which they counter sign it and then send it back to you. If you ever change anything on that Inf file you can do it all over again.
@lutz1410 wrote:
If ideas are nipped in the bud now, the future doesn't look good. If Bill Gates had been given these hurdles in his garage to develop his first OS, there would be no Microsoft today
He also didn’t have internet to easily find every possible information at a key press of the still to be invented Windows computer. And this same internet makes your computer a target under continuous attack.
Every advantage also has its disadvantage(s).
And no, signtool refers to certificates in your personal certificate store to sign the driver or executable with, but your personal certificate store is not where Windows looks for root certificates! That would be very stupid to do as root certificates have a completely different function than your personal ones.
You may even have to convert your certificate first. The one in your personal store contains both the public and private cryptography key. Root certificates are supposed to only contain the public key. Not quite sure you can import your PFX certificate just like that into the root certificate store.
