Select a language to translate this page!
Powered by Microsoft® Translator
To making sure your application is ready (compatible) for Windows 7, I am going to start providing additional information about the few compatibility topics we introduced in the “Is Your Application Ready for Windows 7 RTM?” post. This post focuses UAC Virtualization or more known as Data Redirection.
What Are You Talking About?
Today, many applications are still designed to write files to the Program Files, Windows directories, or system root (typically the C drive) folders. Some applications are designed to update Microsoft® Windows registry values, specifically values in HKLM/Software. But there is one problem: the files or registry values are not created or updated. You may ask, “What’s going on? My application goes through the code and does not report an error. So where are my files?”
To be specific, you may experience one or more of the following symptoms:
If this happens to your application, it is experiencing UAC Virtualization (AKA Data Redirection). The following information provides you with everything you need to know in order to detect this application compatibility problem, offers some solutions, and provides additional information about the specific nature of the compatibility problem.
The Real Issue: UAC Virtualization
Prior to Windows Vista, administrators typically ran applications. As a result, applications could freely read and write system files and registry keys. If standard users ran these applications, they would fail due to insufficient access. Windows Vista improved application compatibility for standard users by redirecting writes (and subsequent file or registry operations) to a per-user location within the user’s profile.
For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory (the Program Files), the write operation will be redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\Contoso\settings.ini. If an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ in the registry, it will automatically be redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso.
The following figure illustrates the two components of the Windows Virtualization process: file virtualization and registry virtualization:
To learn more about UAC virtualization and new UAC technologies, see “New UAC Technologies for Windows Vista” at http://msdn.microsoft.com/en-us/library/bb756960.aspx.
Virtualization is intended only to assist in application compatibility with existing programs. New applications designed for Microsoft Windows 7 should NOT perform write operations to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior. Always develop applications for use with standard user privileges and don’t count on the application running under administrator privileges. Test your application with standard user privileges and not administrator privileges.
If you are experiencing UAC virtualization with applications developed prior to Windows 7, re-design your applications to write files to the appropriate locations. When updating existing code to run on Windows 7, you should:
Steps to Determine the Most Appropriate Solution
So far, we have presented the symptoms associated with UAC virtualization, explained why redirection is taking place, and suggested a solution. This section contains tests and procedures you should perform in order to pinpoint the real problem and plot a way to resolve it.
Hands On Labs and Additional Material
you can download this doc, a presentation describing UAC Virtualization, and two full hands on labs on this topic, one for managed code and one for native, from here.
In order to detect UAC virtualization we use the following tools:
Is there a way to launch an app from the command line with UAC virtualization off without running it as admin? Also, the "Compatibility files" button isn't very obvious. Also, one most useful addition would be to show to the user which legacy app created which compatiblity files.
I know there is some Buzz around Windows 7, but I don't think W7 is so great. At least not for the moment.
@Wedding Invitations Guy - why do you say that? Curious as to why Windows 7 is not so great for you at this moment...
All I want to know is where and how do I install my 40 MB of Access front end .MDEs. (250,000 lines of code). Some users running the 2002 runtime, some running Access 2002, Some running Access 2003 with automatic updates being copied from the server on a regular basis.
AND HAVE IT ALL WORK WITHOUT #$%#% "you don't have rights" or @#$%# "you need administrator privelidges" or @#$%@#% "warning you have macros"...
I mean this all ran fine under 2k and XP and our customers have all been happy as clams. Now they start buying Win 7 and it all turns to @#$%% (we managed to keep everyone away from Vista or the one or two that had it just turned off UAC).
But seriously I don't WANT to know all this stuff, I don't NEED to know all this stuff.
Just tell me WHERE TO PUT MY MDE files and WHAT Security/rights/macro/whatever to turn on or off so the will RUN WITHOUT ERRORS.
ONE install for ALL USERS.
THIS SHOULD NOT BE THE ROCKET SCIENCE YOU ARE TURNING THIS INTO!!
JUST BECAUSE MICROSOFT HAS UNLIMITED FUNDS TO RIGHT REALLY COMPLICATED WAYS OF DOING THINGS DOESN'T MEAN IT IS A GOOD IDEA.
Anyone else remember the automobile industry in the 60s? They just kept adding features and chrome and fins to poor quality products until it got to the point the dealers COULDN'T fix the cars any more - literally they couldn't fix them.
And then the Japanese came along with quality.
@kbmosher as much as I appreciate your feedback, comments should be constructive and respectful.
Pre your question about file location – simple:
File executable, DLL and application dedicated resources – “Program Files”
Application related data, like database schemes, app setting files and such – “Program Data” (type %programdata% in Windows Explorer
User specific data, like user setting, saving specific user information – Local App Data (type %localappdata%in Windows Explorer)
I apologize, I am just extremely frustrated and this is a perfect example of why. You still haven't answered my question.
What is a "database scheme"? What is an "Application dedicated resource"?
What I need to install are Microsoft Access 2002 mde (compiled database) files. They are a hybrid. Essentially they are program files except, of course they are running VBA under MS Access, they also contain a few temporary tables so of course unlike an exe they change.
We have exactly 1 .exe. It is a small program that updates the .mde files. When an mde file detects a new version of itself on the server the mde shells out and runs this simple exe and closes. The exe waits for the mde to close, then copies the new version of the mde from the server to the local machine. The issue with Win 7 is that it redirects this copy process so we wind up in an infinite loop. I have solved the problem by rewriting the the .exe as an mde, and then installing our program (I guess it is not a "program") in c:\Users\Public Documents\Public (one of the many places I have been told is the "New Correct place" for our stuff). From there it seems to update correctly.
Now you are telling me it is %programdata% that I want to install in? The problem with both of these places is, aside form the support nightmare of having more than one install location (C:\Program Files for XP and below and C:\programdata for vista and above) it would appear that the thought is that as a data directory this location should be backed up. What we are installing is, for all intent and purposes, a program. It does ot need to be backed up.
My other choice seems to be to write a "manifest" just so I can update a program in the program files directory. . But can I even create a manifest for an mde file? Or do I have to create it for the Access.exe file? And some users use the access runtime, some use the full version of Access some use both, some use access 2002, some 2003 (We do not support 2005 - to buggy). Do I have to write a seperate manifest for each version?