Labview 2012 Installer builder issues with Windows 7 64 bit

Question

I have a clients project application program I am working on and am having a lot of trouble getting installed applications to work on Windows 7 properly. The Labview Installer sets the default installation directory to "c:\Program Files\" on Windows Xp and on Windows 7 64bit this defaults to "C:\Program Files (x86). When I install the application on Windows 7 and run it, because Windows 7 64 bit unreasonably protects this directory and every folder under it, if you try to write file to any subdirectory under it (like a reports directory), windows 7 will not let the file write to the directory and the file(s) disappear and you get permission errors. This has been difficult to address. Even logging in as administrator, I have difficulty changing the folder permissions. In addition, when I am in the file write process, if the default directory is coded to come up in the file Open/Save dialog, will not properly
go to and display these protected directories. So thinking that OK, I'll just chage the install directory to something direct to the C: drive and not the Program Files (x86) directory, so I have better control of the folder permissions. Now the Installer build gives errors. It built, but the install fails. Looks like National did not test this for Windows 7 very well. I have run into just about every issue possible with Windows 7 and Labview. Clearly Labview was not very well tested with Windows 7 6 bit. I do not have the Internet toolkit added to the application, only the VISA 5.2 driver. Anyone else having application issues with Labview and Windows 7 and have ideas how to work around this?? 
Attachments:
BuildErrors.txt ‏11 KB

Answer 1

It's no NI's fault and has nothing to do with 64 Bit either. It is something MS changed starting with Vista, namely tightening security of the whole system to a similar level as was usual on more professional OSes like Unix 20 years earlier. A user has not rights anymore to write into the location where applications are installed. This is for one reason to protect installed applications from being modified by malicious code.
Instead every application should write its runtime data in one of the user writable loacations such as the user's Documents directory for data files, or in the user's or the machine's configuration directory for configuration settings. For single installations you could always set the directory which your application got installed into to be user writable by changing the rights of that directory afterwards but for applications that get installed on normal user computers this is a VERY hacky and discouraged move. Same about installing your application into the root of your system drive. I think it was an oversight by MS to not protect that directory too from user modifications, but was most likely unavoidable to allow DOS application installations to still work.
LabVIEW has functions to retrieve a whole bunch of those preconfigured and user writeable locations and you really should change your application to make use of those locations, instead of trying to write into the installation directory or installing the application into the root location of the system drive, if you want to be compatible with Windows Vista/7/8.
Windows 7 also requires for a number of actions such as installing programs or drivers so called elevated rights. This means that even if you are logged in as administrator you have to explicitedly provide the admin password again to be able to perform the action. This can be done by starting the program as administrator, when this is available in the right click pop-up menu, and is also sometimes done automatically for applications that Windows determines to need those rights such as setup programs for installations.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions