LabWindows/CVI low-level support driver and Windows 10

[jabaeza2]

I have a Labwindows CVI program in which I use inp and outp to write to a port on an Advantech data acquisition board.

I know that it works through the low-level driver for 32-bit systems, and that it does not work for 64-bit systems.
However, I have not found any alternative to do it for these 64-bit systems.

Do you know of any function, driver or whatever to be able to adapt this program to work on 64-bit operating systems?

[rolfk]

Basically there is no ready made solution anymore that you can simply download from the internet. One of the main problems is that since Windows 7 you can't easily install unsigned device drivers anymore and since Windows 10 it is pretty much impossible unless you switch your Windows system into some sort of debug mode (which is not something you want to do on a production system ever).

Driver signing requires certificates, and certificates cost money! Add to that that such an IO Port driver can be used for many things, including nefarious attempts, also by other people than the one having installed such a driver. A malware tool only has to detect the existence of such a driver (or a number of such drivers) and then can circumvent many security features of modern OSes very easily. Nobody wants his signed driver be used for such things, so nobody is willing to post such a driver for free download anymore. There are some SDK tools that allow such things but you have to buy them and license them for the machines in question, so that takes pretty much care about abusing their drivers by malware.

One project that may still help you, but is not maintained anymore and has some bugs that are detailed but require to rebuild the device drivers and signing of them is here: https://www.highrez.co.uk/downloads/inpout32/

If your application doesn't need the problematic functions you might get away with installing and using the latest 1.5.0.1 version.

[jabaeza2]

Thank you Rolfk for your clear and fast answer.

I'll check if the link works for my case.

I usually work with Windows7 32 bits to avoid this problem, but in this case I was using Windows 10.

It is a pity to have to change hardware in future applications because of this limitation, but if there is no support from the hardware developer nothing can be done. 

[rolfk]

Yes, direct register (and physical memory) access from user space is something that was already bad practice 20 years ago. Many tried to avoid the hassles of creating a real device driver for such things and are now getting bitten by it. With our fast pacing development of computer hardware, the use of any hardware that a manufacturer is not anymore actively supporting, is of course a sure way into maintenance hell for any application that is not just a hobby project, whose failure to install on a new system doesn't mean much more than that your private weather station website stops working. 😁

For any sort of productivity app in a company, it is a liability that is often overlooked and paid manifold for when the system suddenly breaks down and needs to be reinstalled on a new hardware.