Jigar Mehta's Blog : Vista

VirtualStore in Windows Vista

Jigar Mehta — Tue, 11 Sep 2007 22:49:05 GMT

I was researching on one of the issues for my customer and got to read about this registry key.

HKCU\Software\Classes\VirtualStore

This key will be given to applications on vista who tries to do registry operations which requires admin privileges which it does not have. So, the key,

HKCU\Software\Classes\VirtualStore\MACHINE

will be HKLM for such interactive applications. This virtualization is done in order to stop lots of legacy application from breaking on vista. Make note of the fact that all new applications developed for vista should take care of rights given to normal applications and program accordingly (I mean, new applications should not use this virtualstore thing).

Another thing to keep in mind is, this virtualstore is given in HKCU so, if two users runs the same application, they will be getting different virtualstore and will not be sharing the values written by application, so, thats a strong reason not to use this thing for newly developed application.

Stay tuned..

A referral was returned from the server.

Jigar Mehta — Tue, 22 May 2007 23:41:11 GMT

I encountered this strange error while playing with a sample to elevate the executable from the starting. Just imagine, that you require your application to run in admin mode to work successfully; in windows vista, we have the functionality of adding the elevation manifest embedded inside the executable and give user the prompt that elevate the executable otherwise application can not run.

Following is a very good article on how to do this,
http://blogs.msdn.com/shawnfa/archive/2006/04/06/568563.aspx

Following is the whitepaper which might also help,
http://www.microsoft.com/downloads/details.aspx?FamilyID=BA73B169-A648-49AF-BC5E-A2EEBB74C16B&displaylang=en

But while modifying it and playing with my sample code, I got following error.

After little bit of more research, found that GUI applications do not require,

uiAccess=""true"" line.. and if it is there, it would not work.

Solution: So, Solution to this problem is, either remove the line uiAccess=""true"" or else, make the modification and set it to ""false"". After doing the modification, could get it to working properly.

Changes to COM in Windows Vista

Jigar Mehta — Fri, 04 May 2007 04:07:20 GMT

The following changes appear in COM in Windows Vista:

The COM elevation moniker allows applications that are running under a limited user account (LUA) to activate COM classes with elevated functionality. For more information, please see The COM Elevation Moniker.
When you install an application that makes COM calls on a Windows Vista computer, and you plan to run the application as an administrator, you must install the application per-machine, rather than per-user, or it will not function properly.

[Note : Content is from MSDN]

How to programmatically determine whether UAC is enabled or not

Jigar Mehta — Sat, 28 Apr 2007 18:59:27 GMT

The moth says,

This is a question I get often:

"How can I determine if User Account Control is on or off via code?"

The answer I always give:

"You are asking the wrong question. Who cares?"

The point being that, regardless of whether the user has turned off UAC or not, your application should still be partitioned and work correctly for both admins and non-admin users. It is irrelevant if UAC is on or off. You should still display the shields, you should still gracefully fail if the user is not an admin (same as you would if the elevation prompt came up and the user cancelled, same as you should if you were running on XP). The academic answer to the original question is that you can read it from the registry (much like the built-in Security Centre does). Since there is no genuine requirement to know this stuff from code, there is no API for it.

So the only question to answer programmatically is how to know if the user has admin rights. I have shown how to do this before but here goes again:
 // using System.Security.Principle;
  private bool IsAdmin()
  {
    WindowsIdentity id = WindowsIdentity.GetCurrent();
    WindowsPrincipal p = new WindowsPrincipal(id);

    return p.IsInRole("Administrators");
  }
I have read blogs where others get further information regarding elevation about the user's account by pinvoking native APIs, but again, I remain totally unconvinced about that need. Your app shouldn't care about anything else: all that matters is if the user has admin rights at the moment your admin code is about to execute, nothing else.

If you disagree and think you have a genuine reason for knowing more than what I describe above, then please post your scenario to the relevant forum linked to from here.