VISTA Install - Bypass UAC admin rights

[jgcode]

How are developers handling installing on VISTA?

I normally like to store private files in the data folder @ C:\Program Files\<application>\data or similair.

However, the application can not access them with out ticking the checkbox in the executable's properties and turning on administrator rights.

Is there any way to get around this on NI installer?

I have also noticed that VIPM does not have this enabled and it works!

Any suggestions on what to do or any pointers to any information?

There are a few topics on Windows Vista here and here.

NI whitepaper on virtualisation is here and the parent page here

Cheers

JG

[mje]

LabVIEW has handled paths/permissions rather poorly in the past in my opinion. I first stepped on this some time ago working on Linux. Note the following article: http://zone.ni.com/devzone/cda/tut/p/id/7005

The answer to avoiding admin escalation is of course to not put data in system directories. The problem is LabVIEW doesn't really have a good way to determine relevant system directories. It can't handle environment variables, so for example, the path "%APPDATA%\MyApp\Fee.txt" fails to resolve, which is one of serveral places an application might legitimately store it's data without UAC getting in the way on Vista.

Anyways, I don't believe there is an implemented universal solution to this problem yet.

There are of course ways of doing it with a little work. As the article mentions, on Windows platforms SHGetFolderPath (replaced by SHGetKnownFolderPath on Vista or newer, but the legacy function will still work) will resolve paths for you, and FSFindFolder will on a Mac. Linux is more of a mess, there are only conventions to follow, no standard APIs to query.

[jdunham]

QUOTE (jgcode @ Oct 4 2008, 01:04 AM)

How are developers handling installing on VISTA?

I normally like to store private files in the data folder @ C:\Program Files\<application>\data or similair.

However, the application can not access them with out ticking the checkbox in the executable's properties and turning on administrator rights.

Is there any way to get around this on NI installer?

Well Vista is attempting to implement real security, so you shouldn't try to bypass it. Writing stuff into the Program Files folder is not allowed. Rather, you should be writing to the relevant locations in c:\Documents and Settings, which under Vista was renamed to the more sensible c:\Users.

MJE suggested some WinAPI functions to get the right path names, but those are already wrapped by a VI:

http://zone.ni.com/devzone/cda/epd/p/id/3080

In some LabVIEW in the future, this will be replaced by the Get System Directory.vi which was the topic of the discussions you referenced.

[jgcode]

Thanks for the responses guys :beer:

Cheers for the links aswell.

That VI that will work a treat especially since its XP & Vista compatible.

Being a widely distributed LabVIEW product - I am still interested to know if anyone else knows how VIPM works around accessing Program Folders.

Cheers

JG

[jdunham]

QUOTE (jgcode @ Oct 4 2008, 05:42 PM)

Thanks for the responses guys :beer:

Cheers for the links aswell.

I also wanted to point out that there is a big benefit to getting your config data out of c:\Program Files\.... If you want to deliver an upgrade to your program, you can let the installer blow away everything in that folder without losing any user settings or configuration state.

[jgcode]

QUOTE (jdunham @ Oct 6 2008, 01:47 PM)

I also wanted to point out that there is a big benefit to getting your config data out of c:\Program Files\.... If you want to deliver an upgrade to your program, you can let the installer blow away everything in that folder without losing any user settings or configuration state.

Great! Thanks for the tip jdunham :worship: - so I guess I should start doing that for XP too.

Thinking out aloud however, if the installer installs the data files (whether in Program Files or elsewhere) wouldn't the installer know to remove them aswell on an uninstall?

Or is there a built-in proxy in the installer that does not allow such behaviour?

Does anyone know?

If not....time for some testing methinks....

[jdunham]

QUOTE (jgcode @ Oct 5 2008, 11:18 PM)

Great! Thanks for the tip jdunham :worship: - so I guess I should start doing that for XP too.

Well, we learned the hard way, and to be honest, we're still doing it the wrong way until next our next version which has to support Vista.

QUOTE (jgcode @ Oct 5 2008, 11:18 PM)

Thinking out aloud however, if the installer installs the data files (whether in Program Files or elsewhere) wouldn't the installer know to remove them aswell on an uninstall?

Or is there a built-in proxy in the installer that does not allow such behaviour?

Well what has worked for us is that the configuration INI file is not installed by the installer (actually we do install one to fix the fonts, and that has to be in the program files folder, and it never changes).

For the real INI file with our application settings, the one which will go in the user directory, the software checks for it on every startup and creates it if not found (you may want to prompt the user to set the settings at that point too). I suppose your uninstaller ought to remove that file, which would be the polite thing to do, but I haven't tried that.

[jgcode]

QUOTE (jdunham @ Oct 7 2008, 02:22 AM)

Well, we learned the hard way, and to be honest, we're still doing it the wrong way until next our next version which has to support Vista.

Well what has worked for us is that the configuration INI file is not installed by the installer (actually we do install one to fix the fonts, and that has to be in the program files folder, and it never changes).

For the real INI file with our application settings, the one which will go in the user directory, the software checks for it on every startup and creates it if not found (you may want to prompt the user to set the settings at that point too). I suppose your uninstaller ought to remove that file, which would be the polite thing to do, but I haven't tried that.

So your LabVIEW.exe can still access the config ini file in the program folders or is this only for XP?

If so what are your plans for vista - everything to the Users folder?

[mje]

Keep in mind that even under UAC in Vista, you will be able to get at config files located in your your program directory, however the file will be mirrored to a user-specific directory (I forget where, too time pressed to look), so you won't actually be writing to the file you think you are. This will be completely transparent to your program, and not noticeable in a one user environment, but can bring up odd results if you expect changes made to be global for all users since you're actually reading/writing a user specific copy of the config file. I think one of the above linked documents went over that, it's a backwards compatibility thing MS implemented to keep a lot of older apps from blowing up on Vista.

Generally, settings should not be kept in program directories. If you need to make global config changes, I think you can write to the application data folder (%ALLUSERSPROFILE%) without special permissions, by default I believe all users have permission to that folder on Vista systems.

[jgcode]

QUOTE (MJE @ Oct 7 2008, 11:28 PM)

Keep in mind that even under UAC in Vista, you will be able to get at config files located in your your program directory, however the file will be mirrored to a user-specific directory (I forget where, too time pressed to look), so you won't actually be writing to the file you think you are. This will be completely transparent to your program, and not noticeable in a one user environment, but can bring up odd results if you expect changes made to be global for all users since you're actually reading/writing a user specific copy of the config file. I think one of the above linked documents went over that, it's a backwards compatibility thing MS implemented to keep a lot of older apps from blowing up on Vista.

Hi MJE,

Cheers, I did read about the file location transparency.

However, in Vista - Read/Write File Functions return an error in LV if you try to read/write a file you do not have admin access to.

So the transparency only comes into play after you enable admin access.

Other programs don't seem to have this problem - i.e. admin rights is not selected - so there must be a way around this?

[jdunham]

QUOTE (jgcode @ Oct 7 2008, 02:52 PM)

Hi MJE,

Cheers, I did read about the file location transparency.

However, in Vista - Read/Write File Functions return an error in LV if you try to read/write a file you do not have admin access to.

So the transparency only comes into play after you enable admin access.

Other programs don't seem to have this problem - i.e. admin rights is not selected - so there must be a way around this?

The transparency is also called virtualization, because you are allowed to write to a virtual C:\Program Files\ which is not the real thing.

When you install a program, the installer runs under admin privs, and I think at that time you can declare that your app's virtualized folders have lesser privilege. I'm too lazy to look up whether this is the exact truth, but that's what I remember from a bunch of previous googling.

[mje]

Ah, I'm mistaken then. Thanks for the info. I'll have to look more into the virtualization, I think I made a few poor assumptions.

[jgcode]

QUOTE (MJE @ Oct 8 2008, 09:38 PM)

Ah, I'm mistaken then. Thanks for the info. I'll have to look more into the virtualization, I think I made a few poor assumptions.

Seems like there is a bit to find out here...

Just did an uninstall of a LV product. It did not remove a file installed to the desktop but when I click on it I get this:

http://lavag.org/old_files/monthly_10_2008/post-10325-1223470454.png' target="_blank">

Weird!

[Rolf Kalbermatter]

QUOTE (jgcode @ Oct 7 2008, 05:52 PM)

Hi MJE,

Cheers, I did read about the file location transparency.

However, in Vista - Read/Write File Functions return an error in LV if you try to read/write a file you do not have admin access to.

So the transparency only comes into play after you enable admin access.

Other programs don't seem to have this problem - i.e. admin rights is not selected - so there must be a way around this?

I think the virtualization for INI files inside the Program Folder is not realized by virtualizing file IO access to that location but is part of the Windows OS API (GetPrivateProfileString() and friends) used to read INI file settings. Since the LabVIEW INI file VIs are however build entirely in LabVIEW and access INI files through basic Win32 API File functions, this virtualization is not available there.

Rolf Kalbermatter