Windows VirtualStore folder

With a few days off sick for a throat/chest infection I don't have much to do but scour Sourceforge, play games, and make a few of the more interesting ones portable (in between bouts of coughing, sleeping, and feeling like my chest is going to explode and drive my concrete-filled skull through the wall). Thus the recently added dev tests of I Have No Tomatoes and Pentobi, with hopefully more to come.

In the process I found something quite interesting in Windows Vista/7 regarding the %LocalAppData%\VirtualStore folder. This has been touched on very briefly in the forums, and as far as I can recall is not mentioned in the Launcher manual at all, so I thought I would share my findings here for developers (or wannabe developers as I was not too long ago) who have not yet come across this issue.

What does the VirtualStore folder do?
For those who don't know, VirtualStore is Windows 7's way of handling applications writing to locations it thinks the user/application shouldn't be able to (Program Files for example). This is generally because the app in question has been designed to modify files within its own directory. To show exactly what I mean I'll use I Have No Tomatoes as a reference.

The base app installs to the folder Program Files\I Have No Tomatoes. The app stores its settings in config.cfg, which is installed by default in the base app's directory, and also stores high scores in hiscore.lst which is not created until you finish your first game. But what happens when we run the game (without specifying to run as admin) and change some settings or make a high score?

Because Windows will not allow the app to write to anything under Program Files (including its own directory) it instead redirects the file to %LocalAppData%\VirtualStore\Program Files\I Have No Tomatoes. As far as the base app is concerned, anything located under %LocalAppData%\VirtualStore with a path equivalent to its install directory will appear to be in exactly the same place it was originally intended to be (in our case the files are in %LocalAppData%\VirtualStore\Program Files\I Have No Tomatoes, but the original app still believes they are in C:\Program Files\I Have No Tomatoes).

Problems with VirtualStore
The VirtualStore redirect is all good and tricky and protects Windows from programs made to do something Microsoft thinks they shouldn't, but what happens if you then run the app as an administrator?

In typical Microsoft fashion, things break. Instead of going "Hey I have VirtualStore data for this app, I'll use that", or even better "I have VirtualStore data for this app that is newer (and/or exists)", it just uses the data in the install directory. So guess what? Settings are back to the default, and high scores are non-existent, unless you exit the app and run it without admin rights. This also causes the issue that high scores for this game will only ever accumulate on a per-user basis. Nobody who logs in as User1 will see the high scores for User2, and vice versa.

VirtualStore effects on PortableApp development
As long as the files are meant to be in the install directory (as in the example above) we can ignore the redirect to \VirtualStore, as PortableApps should be installed to a location to which the user has write access, so when making I Have No Tomatoes into a PortableApp the following is all I need:

[FilesMove]
config.cfg=%PAL:AppDir%\IHaveNoTomatoes
hiscore.lst=%PAL:AppDir%\IHaveNoTomatoes


If, however, I was trying to do something trickier like import a local app's settings into the PortableApp with custom code, I would potentially have to check both places and compare the last modified date to ensure I was getting the most recent data for the app.

VirtualStore effects on installing and running PortableApps
For those who like to run PortableApps from a local hard drive (as I do on my home PC) VirtualStore is another great reason to never install PortableApps to the Program Files directory. Why bother installing a PortableApp in an attempt to minimize the effect an installation has on your system, to then force your system to handle the VirtualStore redirects for every file changed by the Launcher and the base app? To me, that is like trading a metal bucket half-full of water for a plastic bucket completely full of water because the plastic bucket would be lighter if it were empty.

Potential uses for VirtualStore redirection in PortableApp design
I am not quite sure how the \VirtualStore redirect is done in regards to the installed app itself. Obviously it is more than just appending \VirtualStore\whatever\path to the app's %PATH%, and there is nothing in the Registry for it. I am wondering though if there is the potential to use this feature to fool a portable app into thinking we have installed something it needs to C:\Windows (which is another system folder protected by the \VirtualStore redirect) for those badly designed apps that need such a workaround?