Is there a way to make a LabVIEW EXE built on Windows XP Work on Windows 7?

[smercurio_fc]

My guess is that since you said you are using Windows functions through CLFNs then you must be using a function which was deprecated in Windows 7. You'd need to check which functions you're using and check MSDN to see about its support in Windows 7. If the function is no longer supported then you will need to change the code. Or, run in a virtual machine in Windows 7.

Note: I am not referring to CsrNewThread. I think the problem is higher up in the food chain.

[rolfk]

Yes this DLL has for sure changed, but so have the according DLLs like kernel32.dll and user32.dll that access this DLL. Since the ntdll.dll interface is not really documented, Microsoft is enterly free to do such changes, as they do not need to stay compatible with a documented interface (and anyone having reverse engineered it is entirely on his or her own).

This means that you can NOT exchange kernel32, user32 or any other other kernel DLLs with DLLs from a different system since they form together one complete set that is only compatible if they are from the same version. That is what you probably have a problem with. You somehow copied kernel32 or another Windows kernel API DLL from your XP system to your W7 system and that can NOT work. At best you get such link time errors at load time, at worst you get horrible crashes since one kernel DLL tries to manage resources that are allocated in the other DLL and consequently fails badly, and this being in the Windows kernel has fatal consequences not only for your current process but likely for the entire system integrity.

Make sure you have NO kernel32.dll or any other Windows DLL in your data directory of your app. This can happen if you enter the DLL path name in the Call Library Node fully. LabVEIW considers such DLLs to be application private and copies them into the application distribution. If you only enter the DLL name alone without any path in front, LabVIEW treats the DLL as system DLL and does not copy it into the application distribution. For many DLLs it is not so critical if they are copied as private DLL into the application directoy. For all the Windows sytem DLLs this leads however in most cases to a disaster. This fact is fully documented in the Online Help of the Call Library Node and before you suggest that LabVIEW uses some heuristics to determine itself if a DLL is a system DLL or not, there is no such way to do so, since there are various different DLLs that should be considered system DLLs but it will depend on many things like what Windows version, what Microsoft products and platform add-ons are installed and a myriad of other things that Microsoft does not feel like documenting clearly. A rule of thumb is, that any DLL that resides in the system directory should be considered platform specific but if LabVIEW would enforce that, it would not allow to force driver DLLs for third party products to be included in an application build, which happen to often be installed in that directory too. Personally I think this would be fine, since any driver that installs into the system directory should come with its own installer and that installer should be executed if you want to start an application that depends on that driver, but I know many LabVIEW users who scream hell and mordio if they have to make their users run a second installer besides their LabVIEW application installer.

[aeastet]

If you look in the data folder where your appliaction is located is there a copy of any of these dlls there. If so delete them and try to run your program again.

[Billy_Barty]

Went ahead and upgraded to LabVIEW 2010.  My experience says one should indeed not waste their time trying to get LabVIEW 8.6 (or earlier) working on Windows 7.  Upgrading to LabVIEW 2010 and rebuilding from there creates an EXE that looks like it works on XP and Windows 7.

Thanks,

BB