Jump to content

VISTA Install - Bypass UAC admin rights


Recommended Posts

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

post-10325-1223107379.png?width=400

Cheers

JG

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment

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

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.

Link to comment

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?

Link to comment

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.

Link to comment

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?

Link to comment

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.

Link to comment
  • 2 weeks later...

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.