ANN: Vista "Gotchas" You Should Know About

[Ken Ray]

Hey everyone - I've been working with the release of Vista (Home 
Premium Edition) since its release and just discovered something you 
may or may not be aware of that you REALLY need to be aware of IF:

  - You install your program to the Program Files folder
  - You leave the User Account Control turned on (as it shipped)
  - You have one or more files you need to write data back to (like an 
.ini or .cfg file, or even a Rev or MC stack that you change data in 
and save) that is in the same folder as your program (or a subfolder)

Windows Vista, in attempting to be as secure as possible, and in an 
attempt to support "legacy" applications that have .INI files in the 
same location as the program, when it detects that you are attempting 
to write back to a file in a protected area (like Program Files), will 
instead write the changed data to a NEW location called the 
"VirtualStore", and from that point on, will always READ AND WRITE to 
the file in the VirtualStore. 

So for example, suppose you installed your app as a stub Rev 
standalone, with a main stack file that is read, can be changed, and 
resaved. So your initial installation would put it here:

  C:\Program Files\YourApp\YourApp.exe
  C:\Program Files\YourApp\main.rev

Installation goes fine, and you launch 'YourApp.exe', which in turn 
opens 'main.rev' - you enter some data into a field on the main stack 
and click a button which saves 'main.rev' back to the hard drive. What 
really happens is this:

  1) Vista recognizes you're attempting to write the 'main.rev' file 
back to a protected area (Program Files)
  2) Vista creates a folder at in the VirtualStore and writes the 
updated 'main.rev' stack to this path (assumes a user name of "Ken"):

           C:\Users\Ken\AppData\Local\VirtualStore\Program 
Files\YourApp\main.rev

This is called "virtualizing" the file. You then quit YourApp, and 
relaunch it. YourApp launches, and then goes to open 'main.rev'. Here's 
what REALLY happens:

  1) Vista recognizes that you're attempting to open a file that it has 
"virtualized" into the VirtualStore
  2) Instead of opening the file from C:\Program Files\YourApp, it 
instead opens the 'main.rev' that is in the VirtualStore.
  3) If you make changes to the stack, it saves it back to the 
VirtualStore.

This doesn't sound TOO bad, but here's where the 'gotchas' come in:

  GOTCHA #1: If you leave Account Control on, but decide at some point 
you want to start over from scratch or uninstall and reinstall (perhaps 
an upgrade), if you replace your app in C:\Program Files\YourApp with a 
new version (even one that has been upgraded or has significant 
changes), the next time the app is launched it will open up the 
'main.rev' from the VirtualStore and the user will not only NOT see a 
brand new app, but it will appear as if any upgrades that had been made 
are gone. 
  SOLUTION: To truly uninstall, you need to make sure you delete your 
app from the VirtualStore as well. 

  GOTCHA #2: If you have opened a stack file from the VirtualStore as a 
result of attempting to open it from a protected folder (like Program 
Files), if you ask for 'the filename of this stack', it will NOT give 
you the path to the VirtualStore version of the stack, but will instead 
return the path to the original location in Program Files. So there is 
not (AFAIK) any way for a stack that is open to know if it has been 
virtualized or not. 
  SOLUTION: None that I know of.

  GOTCHA #3: If the user turns off User Account Control, the next time 
YourApp is launched, it will NOT get the file from the VirtualStore, 
and will instead open the file from Program Files. It will appear like 
all the data that had been entered is deleted (resulting in frightened 
calls to Tech Support). 
  SOLUTION: In this instance, the "old" file still remains in the 
VirtualStore, so it can be moved back into Program Files to restore the 
data.

Note that if you turn off User Account Control at the get-go, you 
experience none of these problems - but this is (a) not recommended by 
Microsoft, and (b) something that must be manually done since Vista 
ships with it turned on by default. And I'm sure IT departments won't 
be happy if you request that they turn it off so your program can work 
right... :-)

I'm sure there are more gotchas in Vista, but this was a major one that 
I thought the community should know about.

Ken Ray
Sons of Thunder Software, Inc.
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/