First posted to MSDN on Oct, 15 2007
The last time around
, I suggested that you avoid using the acredir.dll shims - RedirectRegistry and RedirectFiles. As alternatives, I recommended VirtualRegistry and CorrectFilePaths.
Of course, I have already gone into some details on how to use VirtualRegistry to achieve that, but I haven't gone in to any details on CorrectFilePaths yet. And, unfortunately, the documentation isn't much help as of the 5.0.1 release (as I said - stay tuned to the documentation for future releases, as this is something we are working on). In fact, here is all that the documentation tells you:
"Corrects file paths that changed between Windows 95 or Windows 98 and Windows XP Professional. This compatibility fix works by converting the file paths to the correct location for Windows XP Professional in the APIs. For example, a Windows 95 path of C:WindowsWrite.exe is converted to C:WindowsSystem32Write.exe."
While this is true, it is not comprehensive (and is, therefore, not as helpful as you probably want it to be). You see, CorrectFilePaths does apply a number of default corrections, but the real power is your ability to add additional corrections. (You can also configure the shim to not apply the default corrections, using the -b switch.The b stands for base, or bare, or whatever helps you to remember it.)
To add additional paths to correct, you once again have to go into the parameters dialog box. For this, once you have selected (and checked off) the CorrectFilePaths shim, you then need to click the Parameters button. Then, at the command line, you can enter the pairs of file paths you would like to have corrected, using the syntax "old path;new path".
The quotes I have used are not accidental. You see, part of mastering the use of shims on Windows is learning the intricacies of the command lines, and the person who developers each shim is responsible for parsing that command line. In this instance, the command line happens to be space delimited. So, if your paths contain spaces, you'll want to quote them. However, you don't want to quote each path (which is probably what I would have guessed), so "old path";"new path" is wrong. Rather, you want to quote the entire pair, and repeat this for each individual pair if you want to correct more than one path.
Here is an example command line from a redirection that I applied, to illustrate:
“C:WindowsDownloaded Program FilesStockViewer.ini;%userappdata%StockViewer.ini”
Now, one thing you may have noticed is that I have used what appears to be an environment variable. Let's talk about that.
There are a couple of reasons why we anticipated having to use CorrectFilePaths: hard coded file paths, and permissions issues. We either want to redirect a hard coded path, or we want to redirect from a location where a standard user won't have permissions to write to one where they do. (An aside about that: you may be asking why we would need to do this, given that File and Registry Virtualization in Windows Vista will redirect from per-machine locations to per-user locations. Well, we only correct the directories Program Files, ProgramData, and Windows. There are still plenty of applications out there who feel that they are "too important" to be lumped in with the other applications you have installed under Program Files, so they install in the root of the drive. We don't redirect for arbitrary directories, just for these three, so applications like this are going to need a big of a nudge from you.)
Clearly, with hard coded paths being one thing we're trying to fix, we don't want you to have to include hard coded paths in your command line, so we added the ability to get at known locations without that. But, since all you get is a command line, we didn't want to limit you just to environment variables, so we give you a slight variation that lets you get at the value from either an API or a known folder. Specifically, you can choose to use the following variables:
%windir% = value from GetWindowsDirectoryW
%systemroot% = value from GetWindowsDirectoryW
%systemdrive% = first two characters from GetWindowsDirectoryW
%systemdir% = value from GetSystemDirectoryW
%username% = value from GetUserNameW
%programfiles% = value from ShGetFolderPathW(..., CSIDL_PROGRAM_FILES, ...)
%userstartmenu% = value from ShGetFolderPathW(..., CSIDL_STARTMENU, ...)
%allstartmenu% = value from ShGetFolderPathW(..., CSIDL_COMMON_STARTMENU, ...)
%userdesktop% = value from ShGetFolderPathW(..., CSIDL_DESKTOPDIRECTORY, ...)
%alldesktop% = value from ShGetFolderPathW(..., CSIDL_COMMON_DESKTOPDIRECTORY, ...)
%userfavorites% = value from ShGetFolderPathW(..., CSIDL_FAVORITES, ...)
%allfavorites% = value from ShGetFolderPathW(..., CSIDL_COMMON_FAVORITES, ...)
%userappdata% = value from ShGetFolderPathW(..., CSIDL_APPDATA, ...)
%allappdata% = value from ShGetFolderPathW(..., CSIDL_COMMON_APPDATA, ...)
%allusersprofile% = value from GetAllUsersProfileDirectoryW
%userprofile% = value from GetUserProfileDirectoryW
%appexedir% = value from GetModuleFileNameW
So, you can use CorrectFilePaths to redirect to one restricted or moved location to a better one, leveraging these variables to locate the correct spot on a particular installation.
There are some additional details on this shim and how it can be configured. Specifically, we cover a huge set of APIs, you can add some more, or turn some off. But this isn't something you typically have to do. So, instead, I figured I'd give you the stuff you're actually likely to need, and include the rest in the less narrative documentation.
