Why is Win32.dll File Included in a Build's Data Folder?

[alukindo]

Post removed.

Edited January 24, 2011 by crelf
Mangled from the LAVA 1.0 transition

[kennoncotton]

Actually Application Builder will determine if the DLL used in the Call Library Function Node is a system DLL / whether to include it or not based on the way it is referenced in the Call Library Function Node. If you have the full path to the DLL in the Call Library Function Node (c:\windows\system32\win32.dll), LabVIEW will store a relative link from the VI to the DLL and Application Builder will copy it assuming that it is not a system DLL. If the Call Library Function Node only contains the name of the DLL (win32.dll), LabVIEW will not store a relative link and will search the system path to load it and Application Builder will not copy it assuming that it is going to be in the system path of any machine you are going to put the DLL on.

Since you did not include the DLL directly in your project or build specification, I suggest checking all the Call Library Function Nodes in your application. Load your start up VIs and dynamic VIs and go to Edit>Find and Replace and search for the Call Libary Node. You should be able to open each one you find to see where win32.dll is being called and change it to just have the file name and not the full path, save the VI and then try building again. If it happens to be a VI from NI let us know and we'll fix the VI.

Kennon

[crelf]

QUOTE(kennoncotton @ Apr 10 2007, 11:05 PM)

If you have the full path to the DLL in the Call Library Function Node (c:\windows\system32\win32.dll), LabVIEW will store a relative link from the VI to the DLL and Application Builder will copy it assuming that it is not a system DLL. If the Call Library Function Node only contains the name of the DLL (win32.dll), LabVIEW will not store a relative link and will search the system path to load it and Application Builder will not copy it assuming that it is going to be in the system path of any machine you are going to put the DLL on.

But how does it *know*? Is it that the DLL is in the search path somewhere, or is it limited to only the system path? Also, what if the win32.dll is different betweek systems? eg: what if it's built on Windows 2000 and then run on WinXP? I figure both of these OSes have a win32.dll, but are they the same (enough) for this to be a robust thing to do?

[kennoncotton]

QUOTE(crelf @ Apr 10 2007, 11:23 AM)

But how does it *know*? Is it that the DLL is in the search path somewhere, or is it limited to only the system path? Also, what if the win32.dll is different betweek systems? eg: what if it's built on Windows 2000 and then run on WinXP? I figure both of these OSes have a win32.dll, but are they the same (enough) for this to be a robust thing to do?

LabVIEW decides whether to use a relative link or system search path based on what you type into the 'Library name or path' control in the Call Library Function configuration dialog. If you put just a name, when you press OK LabVIEW will search your system path (and then your VI Search path, I think) for the library and load it from there. If you put in a path when you press OK LabVIEW will verify the DLLs existance and store a relative link from the VI to the DLL.

Using just the library name does mean if your path environment variable is different on different machines you may get a search dialog on other machines. And yes if the DLL is different on different systems you could have trouble, if there is a function available in XP that is not in 2000 your VI will be broken, if the parameters differ the call could fail, if the underlying code is different then the behavior could be different. The OS calls I've used and seen others use Microsoft generally does a good job keeping the API compatible (at least on all NT OSes, 9x<->NT has differences). If there is a difference in the API then a case structure or conditional disable or dynamic VIs can be used to call the correctly configured instance.

I would say in general it is a robust enough thing to do, but obviously test on all the platforms, specifically in areas where you are concerned there may be a platform difference. The http://sine.ni.com/devzone/cda/epd/p/id/4935' target="_blank">Windows Utilities LLB for instance has been around since LabVIEW 4 and Windows 95? / NT 4? and still works. There is a DLL included in the .zip but many of the VIs call directly into the Windows DLLs