Preset install folder for Vista and Windows 7

In Vista, every program is expected to work with three different folders:


 * Program location
 * Program initialisation files
 * Current folder for files saved by the user

All of these are separated further into per user and global locations.

It's an office / document type model, and is ideal for e.g. word processors and similar programs, But it can be harder to fit other types of programs into the model.

This system existed already in XP but was optional - and indeed on XP not many programs followed the model.

The Virtual Store in Vista and Windows 7
In Vista and Windows 7, the system is strongly enforced by the operating system, to the extent that if you install a program into C:\Program Files, then it can't save files into its own install folders. Even it's .ini files can't be saved there.

It's recognised that many existing programs don't fit this model. So Vista deals with programs like this by creating a "virtual store". The virtual store is the true location for any files your programs attempt to save into your Program Files folder.

The files don't actually exist in your Program Files folder at all. However they appear to be there if you look at them using the Open and Save As windows within the program - the Open and Save As dialogs will show the files within the program location folder - but then when you look for them in Windows Explorer they aren't there.

The program itself also "sees" them there as well, e.g. if it checks if a file exists after saving into the install folder, then the Windows routine will report to the program that it exists even though it really only exists in the Virtual Store.

The files don't turn up in hard disk searches or if the user explores the folder
If you do a search of your hard disk or explore the folder for the program, you find that the files you saw in the Open and Save As windows don't exist there.

You probably won't be able to find them anywhere on your computer. To find them you need to switch on the option to show hidden system files, as the real virtual store is hidden in Vista and Windows 7. Most users would be well advised not to show those files.

This works up to a point
This works well up to a point - users get the impression that they are able to modify the contents of the program folder and modify files there from within the program and so all goes well up to a point. But things aren't quite as they seem - and this on occasion can lead to confusion.

Disadvantages
Disadvantages of relying on the virtual store for these programs include:


 * If you search your hard disk for a file you just saved, you will often find that it isn't where you think it is. Normally you can't find it anywhere at all.
 * A backup of the entire program folder can omit the files that only exist in the virtual store. E.g. if you just copy the folder using your Windows Files Explorer, the copy will not include any of the files from the virtual store.
 * If you uninstall a program from Program Files, and then reinstall it into the same folder again, then all the old files "magically" reappear. That's because the uninstaller can't remove the copies of the files in the virtual store so they are still there after the uninstall.
 * You can't do a clean uninstall then reinstall in Vista with UAC because of this "reappearing files" issue. The only way to do it is to reinstall into a different folder from the one you uninstalled from - or if you find and erase its virtual store before the reinstall.
 * Files that are in the virtual store  can't be  started up by file association from within the program itself - because they aren't where they seem to be to the program. E.g. if the program saves a text file and then tries to show it by file association in Notepad, then Notepad will just say that the file doesn't exist because it's in the virtual store rather than the expected location.

These issues have arisen in support for my programs. They can puzzle users, and can be tricky to resolve. For some simple programs the Vista solution is fine but for mine it causes much puzzlement.

Solution 1 - Switch of UAC
It is best to avoid this whole situation if one can. One solution of course is to switch off User Account Control. This works because it is UAC which is responsible for maintaining the Virtual Store. Many however will want to keep it on for its extra layer of protection from malware. And I would want to recommend that it is kept switched on as well.

Solution 2 - install into a different folder
I have been unable to find any recommended folder for such programs in the Microsoft documentation. But I have found out that some other legacy installers install into:

That seems as good a preset as any for an "unofficial" standard.

Other programs that follow this single folder type model install directly into Drive C but that could lead to a proliferation of sub folders of the root C making navigation potentially confusing. So - though not perhaps ideal, c:\Programs seems perhaps the best alternative I can find so far.

An alternative some users may prefer is be to create a Programs sub folder of your My Documents folder and install Tune Smithy there instead so you can find it easily.

You do get things saved there that rather stretch the notion of a "document". E.g. Microsoft's Virtual PC uses My Documents as the folder to save its Virtual Machines into.

Solution 3 - rewrite your program to try to follow the office / documents type model
I have considered other alternatives but not come up with anything convincing yet. A rewrite of the programs to follow the Vista model was one option I explored briefly. The problem is that the programs I write just don't fit this model very well.

Advantages of the single folder type install model for the programs
The single folder type model has advantages for small programs especially if you want the program folder contents to be accessible to the user.

It means everything the program modifies is in one place - rather than proliferating throughout your system in 3 or more different locations. If you want to move the program to another computer you can just copy the folder. The user can also install the program on a USB drive and since it is all in a single folder, the program on the USB drive won't attempt to modify the system so can be run on another computer directly from the USB stick.

For the type of programs I write, these advantages seem to outweigh the disadvantages, so even with new programs I still use this simpler all in one folder type approach.