LabWindows/CVI
LabView / NI development under Windows 10
I think requiring NI or LabWindows/CVI support to solve this problem is the possibly worst scenario you can follow. It is a third party device (ZEBRA) and involves something that has to do with installing the correct device driver into an OS (Windows). Both of those have nothing to do with NI or LabWindows/CVI-LabVIEW.
It seems you have in the past used a VISA Raw driver for directly calling this device. Unfortunately Microsoft decided that they do not want to allow unsigned drivers to be installed in the Windows kernel anymore. This has both a commercial and technical reason. In order to get the necessary certification that clears the path to use their Windows OS in government offices, they need to follow certain common rules. One of them is to not allow random device drivers to be installed in the kernel since such a device driver can virtually do ANYTHING with the system if it wants to. So you want to be reasonably sure that the driver that is getting installed is actually the driver that the label on the box claims to be rather than a trojan or crypto locker in disguise. For this, signed drivers provide a certain assurance. This can't guarantee that the driver is not such a baddy, but it can guarantee that if the driver claims to have been created by Great ACME Corp, it was actually created by Great ACME Corp, and not some hacker group in some dark corner of the world. If Great ACME Corp decides that they want to destroy their reputation anyways and turn themselves into an outcast, you are still hosed, but most commercial companies would try to avoid that at pretty much any cost, so it is still reasonably safe.
An NI VISA Raw driver is unsigned by default. NI can't sign it for you since they do not know what you plan to do with it and in fact it is created by you with the Driver Wizard even if you didn't write a single line of code for it. If you want to be able to install that driver on a modern Windows system you will have to invest into getting a Signing Certificate from a globally recognized Certificate Authority. These do not cost your arm and leg but you have to be prepared to part with 300 to 500 bucks per year to obtain such a certificate. Then you can create a signature file for your VISA Raw INF file and then Windows will be able to accept it as a valid driver.
There is potentially an extra complication though. Since Windows 10 release 1607 or so, the device driver installer will not be happy with just a self signed driver file but require a Microsoft signed driver. The way this is supposed to work is that you have to run your driver through a suit of test programs from Microsoft that you can run yourself on your machine, and which will create a signed test report about the driver operation, then submit the signed driver with that test report to Microsoft and they will then amend your signature with their own and send the signed driver back to you if they determine that the test report indicates that all tests have been successfully finished. One extra thing here is that the Certificate to sign a driver that is to be submitted in such a way, has to be a so called EV certificate. This means that the Certification Authority actually has checked that you are really the person or entity you claim to be. These certificates cost a bit more than a simple standard certificate as the CA has to perform extra work for it to verify that the person or entity requesting it is really that person or entity.
There are exceptions to when a Microsoft signed driver is required, and it gets complicated. But that is how installing kernel device drivers works nowadays also on Mac OS, just to name one.
@gdargaud wrote:
That that is why, for driver development, it is SO MUCH easier to do under Linux... I gave up Windows driver devel long ago.
It depends what you mean with driver. Most people mean apples in one case and oranges in the other.
Driver development under Linux isn't necessarily easier especially if you talk about kernel drivers. Yes a kernel device driver can be initially very simple if you can just reuse an existing driver as template and do minor modifications to it. But that driver will be pretty dependent on a specific kernel version and soon get a nightmare to support if you want to distribute it to others. Non-source code drivers are anyhow a real problem, and that is on purpose, since the kernel developers want to discourage non-open source kernel drivers as much as possible. But even if you distribute the source code it is going to be problematic as newer or older kernel headers may not be compatible with your code.
I admit that developing Windows kernel drivers is definitely a completely different league of problem. Here it is immensely difficult to get a fully working driver that doesn't do bad things to the system. But once it is developed and tested it works on pretty much any Windows system.
If you talk about higher level drivers such as instrument drivers, the differences are much smaller. And the intermediate layer often comes down to the fact that under Linux you do have to program in C or similar to be able to do it at all and users working on Linux are used to that fact. Under Windows most users expect an out of the box experience and that works fine if you have some ready made instrument with its ready made vendor supplied application but starts to break down if you try to communicate to that instrument through another method.
Many hardware can't be used under Linux at all, simply because the according hardware or protocol documentation is not available. Reverse engineering these things can sometimes help but only goes so far. Even reverse engineers have usually a life of their own and get fed up after a while digging into internas of products that may or may not stay the same with the next product revision.
