Labview 2012 Installer builder issues with Windows 7 64 bit

[SunshineDesign]

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?? 

[WishKebab]

Hi SunshineDesign, 

I'm no Windows expert, but from what I understand, logging in with an "administrator" user account in Windows 7 does NOT mean you have full administrator privileges.  Under normal circumstances, you still have to individually specify which programs you want to have full administrator rights by right clicking the program and selecting "Run as Administrator."  I have no idea why this is the case :(.

The following link details some of the differences in user accounts and shows how to enable or disable the hidden "elevated" administrator account (apparently not recommended): http://www.sevenforums.com/tutorials/507-built-administrator-account-enable-disable.html?filter

[rolfk]

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.

[jonathanupr]

Hey there. I am running into a similar issue that is being discussed.  I am needing to create an Excel file in a folder, write to an Access file, and read from them as well.  The present directory we use is within the Program Files folder, thus we have to allow for security settings changes to be able to programatically access our files.

On a Windows 7 PC, what directory would be a good one to write our data files into?  I saw the noted "Documents directory for data files" ...but where is this on the C Drive?  What path would this be?

Thanks for the informative post.

[rolfk]

It's typically C:\Users\<user name>\Documents\<your app name>. But you can't and shouldn't attempt to hardcode this in your application. Instead use the "Get System Directory" VI to retrieve the "User Documents" path and append your app name to it.