Any issues using EXEs built with Win7 on a WinXP PC?

[george seifert]

I'm going to need to develop LV code (LV2011) on a Win7 PC that will be used on a WinXP PC. I'll be building an executable and an installer. Are there any known issues with doing this?

George

[hooovahh]

A few things to be aware of is the application may look different because of the themeing controls and fonts that are used are different.

Also be aware that with UAC in Winodows 7 you may not have the ability to write registry. Even as an administrator you need to turn UAC down to be able to write in most of the registry (user access may work I'm not sure).

Not specifically XP to 7 but also be aware that with 64 bit Windows OSs have a "Program Files (x86)" folder and that hard coded paths to C:\Program Files are bad.

That also reminds me that hard coded paths to "C:\Documents and Settings" are also bad and should be using system variables to user files or temp files.

Assuming you avoid, or are aware of these issues it should work just fine.

[Tim_S]

hooovahh has the right of it. I updated code to work with Win7 last year; the main gotchas were accessing the registry and directories because of the UAC. I found that the program has to request higher level access to get to the registry, so I chose to eliminate accessing the registry all together. The installer put the application with its configuration files in the Program Files directory; Win7 wouldn't allow modification of those files (possibly also requiring requesting higher level access?) so I had the application go into "C:\<app name>\" instead and the commonly modified configuration files go into to the all-users application data folder (per Microsoft website). I could have turned off the UAC entirely and not made any changes, but the software will get installed on a variety of network setups depending on the specific plant's IT so it was better to follow MS's guidelines.

[asbo]

... so I had the application go into "C:\<app name>\" instead and the commonly modified configuration files go into to the all-users application data folder (per Microsoft website).

If you can access the application data folder fine, why did you move the application as well? I ask because I feel that applications burrowing into my root folder is messy and crude. Granted, on test PCs this rarely matters.

Additionally, if your application configuration does not explicitly need to be accessible by all users, an application will always have write permissions to the user's My Documents folder (unless it's been deleted, of course, but I've never seen this in practice).

[george seifert]

Thanks for the replies, but we might be getting off topic now. I was asking about developing on a Win7 PC and using the executable on a WinXP PC. Maybe Win7 specific issues should go in another thread.

[Tim_S]

If you can access the application data folder fine, why did you move the application as well? I ask because I feel that applications burrowing into my root folder is messy and crude. Granted, on test PCs this rarely matters.

The code updates some typedefs in dynamically loaded code. This couldn't have happened with the default UAC if the code was in Program Files. I vaguely recall having some issues with opening VIs through VI server, but can't recall them at the moment. This was with LabVIEW 8.6; I'm not certain if 2011 would work differently.

Additionally, if your application configuration does not explicitly need to be accessible by all users, an application will always have write permissions to the user's My Documents folder (unless it's been deleted, of course, but I've never seen this in practice).

Most of our systems go on plant floors. We lock the systems down hard for the autologin user when we can as we've gotten too many calls from customers of poor system performance to find out that the operators have been playing games, doing homework, surfing the internet, etc., on the machines. There is a second "supervisor" user for the plant engineers, IT and us to debug and update the system. The plant IT I've worked with when our system is on their network does something similar (though not usually as aggressive). We had one plant that didn't do any of that; it took a week and a half to get them back up running full production while we cleared out the viruses (they are now a believer in imaging hard drives as well).

[asbo]

Thanks for the replies, but we might be getting off topic now. I was asking about developing on a Win7 PC and using the executable on a WinXP PC. Maybe Win7 specific issues should go in another thread.

I guess it wasn't clear you weren't referring to usability of the code. There is no issue with building an executable on one version of Windows and running it on another, so long as the bitness (x86 vs x64) and LV runtime versions matches. In both cases, the program won't try to execute if it doesn't have the correct prerequisites.

The issues we were discussing have more to do with the practical question, "Will code I write on a Win7 PC always work on a WinXP PC?"

[Roger_1]

The installer put the application with its configuration files in the Program Files directory; Win7 wouldn't allow modification of those files

I had this problem with Win7 but fixed it by unlocking the folder in the project "Build Specifications".

Under "Source File Settings", select your destination folder below the "Program Files" folder and set the "File and Folder Attributes" to "[x] Unlock".

[Tim_S]

I had this problem with Win7 but fixed it by unlocking the folder in the project "Build Specifications".

Under "Source File Settings", select your destination folder below the "Program Files" folder and set the "File and Folder Attributes" to "[x] Unlock".

Just a note that LV 8.6 doesn't have that option, but 2011 does. Not sure about inbetween.

[Roger_1]

Run the executable as Administrator in Win7 to allow it to modify files in the "Program Files" folder.

Create a shortcut to the executable and select properties. Select the "Advanced" button. Check the "Run as administrator" box.