Applications and WinXP/Win7 problem...

[joedowdle]

So I built an installer/applications and they install and work correctly on the machine I built them on (Windows XP w/ LabVIEW 2010 SP1).  I brought them over to a laptop that has Windows and it has an evaluation verion of LabVIEW on it.  Either way I'm pretty sure I've included all the run-time engines needed for using it as a standalone app. 

Everything installs correctly and on the WinXP computer I get no errors.  Repeating everything the same results in an error from trying to open/copy a file.  Error 8 - I think it was.  All the files paths are correct and adjust automatically between run-time and development systems and work on the XP computer both from a VI stand point as running as an application.

Any ideas what might have causes this error going from WinXP to Win7?  Thanks.

[LV_Pro]

Possibly the enhanced security issues on Win7? Are your accounts on both machines at the same (i.e. admin, etc.) level. Error 8 is a files permissions error, so I guessing that it is the security.

[joedowdle]

I tried it on my personal laptop with Win7 and it worked just fine.  File permissions were the problem.  Do you know what security feature needs to be changed to allow this operation?  Thanks.

[Taki1999]

Check the permissions on the file and destination on your laptop and on the target machine.  My guess is that your laptop allows you full control of the file in question while the installed app on your target probably defaults to read only.

I haven't worked too much on Win7 but I think the Accounts Manager allows you to set default file permissions for different groups.

[Norbert_B]

Windows 7 does by default not allow a non-superuser to make changes to the "program files" directory once an installer has created/copied files in there. As far as i know, XP does not have this harsh restriction. Maybe, this is the source of the error.

Hint: If so (and you need to run the application nevertheless within your user login), you can place a short cut on the desktop and link it to your application. In the link, configure the linked application to be executed "run as administrator" (shortcut property dialog >> shortcut >> advanced), which will enable this application to modify files in the program files directory. Please check with the local IT department before configuration though.......

hope this helps,

Norbert

[joedowdle]

After going over some things, I'd like to avoid requiring a user to have admin privileges to run the program.  Are all the directories in Win7 this way or could I use the ...Users\login\folder directory to write to?  I'm not familiar with admin/versus non-admin restrictions.  If no one knows off hand I'll just have to give it a try.  Thanks.

[Wayne.C]

stupidlogic,

The key to Win7 is a hidden directory named "c:\ProgramData".  This is where Win7 expects files that an application might need to modify (Public Application Data).  An .ini file for instance.  If you take a look at this directory on a Win7 machine you will find that many applications installed on that machine have their own folder in this location.  WindowsXP has a similar scheme.

Take a look at 'Get System Directory.vi' and how it can determine, based on OS the proper path to use for 'Public Application Data'.

What verison of LV are you running?

[joedowdle]

I'll have to take a look at that.  I've only been using LabView for about 2-3 months now so I'm pretty new.

I'm using LV 2010 SP1.

Thanks.

[Wayne.C]

stupidlogic,

Also note that 'Destinations' section of a build specification for an installer includes [ Public App Data ] folder.  This allows the installer to install the files in the right location based on OS.

I've now built several apps that load on XP or Win7 with no security problems at all.  I used to always have to fight with XP.  Turns out it was becuse I wasn't using the 'Public App Data'.