LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Out Port & run-time module

I'v got a problem... My VI uses VXD driver (throw the DLL) to get the board information. In one particulary case i use OUT PORT VI, provided by LabVIEW, to bypath driver. BUT! It works with the LabView, but on the other computer, with run-time module only, I get error (A subVI, Type Definition, or external subroutine is missing or inconsistentwith the current VI). When I try to start run-time module on the first computer, it works. What I have to do?

0 Kudos
Message 1 of 4
(2,395 Views)

What's the OS on the other computer? (see also this discussion)

0 Kudos
Message 2 of 4
(2,386 Views)

First, technically it is not a VXD driver. That were Windows device drivers from Windows 3.1 and Windows 9.x. For all Windows NT based versions VXD drivers never were an option but you need instead a kernel driver (*.sys).

Second the CVI Low Level kernel driver used for this functionality makes use of a semi published kernel API in Windows that was already declared depreciated in Windows 2000 with the warning that it may be removed in future versions of Windows. Microsoft never went through with that threat for the 32-bit versions of Windows, but axed that kernel API without any remorse for the 64-bit versions of Windows. So even if NI had recompiled the CVI Low Level kernel driver for 64-bit, it simply wouldn't work. That is why these low level IO functions can't work on 64-bit OSes.

In these days of OS security being a major concern everywhere, such a broad door into the underlaying hardware is simply not of these times anymore. With this driver you can basically brick your system by a simple accident to the point where you can't easily repair it yourself anymore. What is worse, a virus or trojan can do this too without any special privileges if it is aware of this driver or gain access to the underlaying BIOS infrastructure and circumvent all the security built into the OS in an instant. If you need to access hardware registers in a modern OS you really need a dedicated kernel driver specifically for this hardware. Hacking registers may be ok for your embedded circuit, but not a general purpose computer anymore.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 3 of 4
(2,346 Views)

@rolfk wrote:

First, technically it is not a VXD driver. That were Windows device drivers from Windows 3.1 and Windows 9.x. For all Windows NT based versions VXD drivers never were an option but you need instead a kernel driver (*.sys).

Second the CVI Low Level kernel driver used for this functionality makes use of a semi published kernel API in Windows that was already declared depreciated in Windows 2000 with the warning that it may be removed in future versions of Windows. Microsoft never went through with that threat for the 32-bit versions of Windows, but axed that kernel API without any remorse for the 64-bit versions of Windows. So even if NI had recompiled the CVI Low Level kernel driver for 64-bit, it simply wouldn't work. That is why these low level IO functions can't work on 64-bit OSes.

In these days of OS security being a major concern everywhere, such a broad door into the underlaying hardware is simply not of these times anymore. With this driver you can basically brick your system by a simple accident to the point where you can't easily repair it yourself anymore. What is worse, a virus or trojan can do this too without any special privileges if it is aware of this driver or gain access to the underlaying BIOS infrastructure and circumvent all the security built into the OS in an instant. If you need to access hardware registers in a modern OS you really need a dedicated kernel driver specifically for this hardware. Hacking registers may be ok for your embedded circuit, but not a general purpose computer anymore.


Thanks for this . 

0 Kudos
Message 4 of 4
(2,302 Views)