Home‎ > ‎Tech Articles‎ > ‎

Windows UAC Integration With Legacy Programs

So, it’s going to happen, you’re in the process of migrating from Windows XP to Windows 7, then you run across some critical applications that don’t seem to behave in Windows 7. What are you going to do?

 You have two basic options, get an updated version of the program, or make the current version work with Windows 7. The first option may not be feasible, especially if it is a custom application.  The developer of your old Fox-Pro or Access application may have long since retired and is sitting on a beach in the Bahamas ordering a Mai Tia with his new iPad, while you are stuck trying to get the program working. So in your case, one of the best things to do is understand how Windows 7 interacts with legacy applications.

 In this blog post we will discuss briefly UAC in Windows 7 and how it can affect older programs.

 UAC stands for User Account Control. In a few words it’s Microsoft's way of securing your computer from... yourself. It’s a way of keeping you from accidentally changing system-wide settings or installing software that can affect the entire computer such as a virus. In effect, even-though your user account may be an administrator on a computer, you do not run with administrative rights. You run as a standard user, and if you are an admin and you try to change something that requires administrative privileges, you are asked to confirm this, then you are temporarily granted the rights you need.

 To see an example of this you can login to a computer with UAC enabled with an account that has admin rights.  Click on your start button and in the search box type “cmd”. Left click on the command prompt icon to open it. Now change to the C:\Windows\system32 directory with the following command: cd c:\Windows\System32 . Now try to make a test directory, with the following command: mkdir test . What happened? You got an “Access is denied” message like below:

 But how can access be denied to you, you of all people, you are the administrator! Ahh yes; with UAC you are running as a normal user, and as a normal user you do not have rights to write to C:\Windows\System32.

 Now click on your start button again and search for “cmd” again. This time right click on the icon to bring up the context menu as shown below:

 You see that little shield icon? Whenever you see that icon, you know if you click on that option, or button, you will be elevating yourself to the super user or admin to run that command. So go ahead and click on the “Run as administrator” option. Now you are presented with the UAC or “User Account Control” dialog box. This is telling you that you are about to run something as the administrator, so be careful. Go ahead and click Yes.

 Now if you notice the title bar it says “Administrator” to let you know you are running with admin rights. Now type cd c:\Windows\System32 if you are not already there and type mkdir test . What happened? It happily allowed you, running in administrator mode, to make the change.

 So this is a big change, in Windows XP if you logged in as an administrator, you could do whatever you wanted, no questions asked. Now, with UAC, even if you are an admin, you must request permission.

 So now, how does this affect your legacy applications? Many applications would run fine as a standard user, however they were designed to needlessly store user specific data in system areas of the registry and file system, such as HKLM\Software or C:\ProgramFiles.

 So how does UAC try to help the old applications run? It uses file system and registry virtualization. Windows will allow reads from the system areas, but any writes are redirected to virtualized locations. The following are the redirected file system locations:

%ProgramFiles% (\Program Files)
             %AllUsersProfile% (\ProgramData – what was \Documents and Settings\All Users)
             
%SystemRoot% (\Windows)
             
%SystemRoot%\System32 (\Windows\System32)

 If an application tries to write to these locations it is redirected to the following per-user virtual root directory: %UserProfile%\AppData\Local\VirtualStore. The exception to this virtualization are executable files (.exe, .bat, .vbs, etc) for security reasons Windows will not redirect those writes, you will just get access denied.

 The following are the redirected registry location:

HKLM\Software (with the exception of some keys under HKLM\Microsoft)

 If an application tries to write to these locations it is redirected to a per-user virtual root of:

            HKEY_CURRENT_USER\Software\Classes\VirtualStore

 So, what does this mean? Well if you have an old program that is not functioning properly, and you can’t figure out why, try looking under these virtual root locations above and see if your program is writing data there.

 If it is, you can try adding some additional file extensions to the exclude list, so Windows will not redirect those types of files. You can do this by adding the file extension  to the following registry key: HKLM\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd

 Well I hope this blog helped you understand a little more what UAC is, what it does, and how it can affect your programs.

 

Happy computing!