labview app developed in Win XP wont install properly on win 7

[id]

I developed an app which had hard coded path filenames and built the installer to install them in those specific directories.  I.E. : c:\Program Files\app\myfile.txt.  I ran this installer on a win 7 machine and it put the files in the directory C:\Program Files x86\app\myfile.txt.  As a result, the program does not work because it is looking for the file in the original directory where it isnt.

How do I get around this problem and allow my app to be installed in either Win XP or Win 7?

[smercurio_fc]

Simple. Don't hard-code paths in the code.

What kind of answer were you expecting?

[dan_u]

For instance, you could work with relative paths (relative to the exe location).

If you modify these files from your application it would be better to store them in the application data folder or some other path since the program files folder is "protected" in Windows 7.

[PackersFan]

There is also a VI in LabVIEW that will give you common OS paths, such as the Public User Directory, Program Files directory, and so on.  You could use that and those paths in your installer to build a relatively OS independent path.

[K.Waris]

copy your text file from C:\Program Files x86\app\myfile.txt and place it in  c:\Program Files\app\myfile.txt.

Both directories program files and program files x86 exist in Windows 7.

[id]

The "Get System Directory.VI" returns all kinds of paths not listed in things like tools>options or the project builder dialogs.  Some of these dirs are labeled as user ones and others for the app which is confusing.  Is this the latest directory struture labeling for the Win 7 approach or somehting?   What is the applicability of this VI - do you use it in your program to get the actual system dir settings that the program is operating in and then concatenate the path names to it? 

Any help is appreciated.

[RavensFan]

User ones relate to the user directories such as My Documents.  There are the personal user directories that are accessible to each person who logs on, and the All Users directory that is accessible to everyone who log on.  The paths to these directories have changed from Windows version to Windows Version.  The "Documents and Settings" path under XP, I believe is now "Users" under Vista /Win7.

The program file directories point to the default locations for program files.  Under XP it was c:\Program Files.  With Vista and Win 7 and the 64 bit vs. 32 bit programs, they renamed them.  Most programs are still 32 bit and are put into c:\Program Files (x86).  The rare 64 bit programs are put under c:\Program Files.  So the program file path as effectively changed from older Windows to newer for the majority of programs.

Yes, you use that VI to get the Windows version specific paths and concatenate path information to that rather than using hard-coded paths.

[id]

As I develop a new app that is both Win XP and Win 7 operable, then I should use the Get System Dir.vi for ease of cross operation? It appears that this is the replacement for several older labview dir functions.

I found a great web example at https://decibel.ni.com/content/docs/DOC-21242 which describes the paths and how they change between development env and executable targets.  They use the older Labview Dir Functions like "default data directory" to get the paths that were entered into tools>options out to the programming interface.  There is a lso a good example of how this interrelates to the project build and installation dirs for the exe files https://decibel.ni.com/content/docs/DOC-9267.

Since this new Get System Dir.VI has many more selctions, have these features been incorporated into the project build tool?

. 

[PackersFan]

Many, though not all, of these OS paths are available when building installers as destinations.

[smercurio_fc]

That second example you linked to has nothing to do with project build or installation directories. It is an example that is related to this: Why Does My Executable Not Work When Using the Current VI's Path Constant?

---

@id wrote:
Since this new Get System Dir.VI has many more selctions, have these features been incorporated into the project build tool?

---

What exactly are you asking here? The building of the installer uses symbolic names for where the files should be placed (ie., "Program Files" to indicate whatever folder is specified as the installation directory). Thus, a user can select to install the application onto some other drive, such as "E:\YourApp", instead of "C:\Program Files" (or "C:\program Files (x86)" on a 64-bit system). There should be no reason for you to set these paths in the installer specification. This simply moves the path hard-coding from the code to the installer. How is this any better?

Your code should use the Get System Directory VI to get the paths programmatically.

You should also keep in mind that Windows 7 has further restrictions on the "C:\Program Files" and other folders (such as the root drive). This has come up before, so you can search for these posts. If you want to save something programmatically, under XP it was not an issue, but under Windows 7 it will be an issue if your target is the "C:\Program Files" directory, if that's where the application was installed. Microsoft created the "C:\Program Data" folder for post-installation, run-time saving of files by the application.