JTMoleBoxed wrote:For instance, you said, on Oct 22: " If you have a folder with some application, select the main exe and drop other files in the Files tree, in the %DEFAULT FOLDER%." Do you mean that I should include in the file tree all the files in the installation folder EXCEPT the main executable, which will then only be listed in the "Input file name" line? Or, should the main executable also be listed in the file tree?
You should not add main executable in the files tree.
Main executable is a core of application. All other files will be handled around this core.
So main executable should be selected as a file for packing, and all other files added in the files tree.
JTMoleBoxed wrote:In terms of folder structure, should %DEFAULT FOLDER% always be the top level folder included under "Virtual Box files," even if the real location of the files in the file system is "Program Files\Target app" and "ProgramData\Target app?"
This does not matter where your application is installed. It could be installed in Program Files folder, in the root folder of disk C: or on the flash drive. There, you should think that you have a folder with the program. The folder with the program is named %DEFAULT FOLDER%. In this folder, there are located all main files of the program, and especially - main executable.
So %DEFAULT% folder is a folder where the main executable is located.
If, for example, your program, reads some files from %MyDocuments% folder, then %MyDocuments% can be added to the tree too (if it is necessary and if you would like to hide/virtualize files form this folder too).
JTMoleBoxed wrote:From the preceding example, you can see that I am working with an app installed in Vista. However, if I select "new folder," I find that a number of the provided environment variables point to folders in XP installations that are no longer available in Vista, while folders only found in Vista are not present. How would I then designate folders appearing only in Vista, such as Users and ProgramData?
Why not, there are such folders. If you right click on the files tree and select Add Root Folder, you will see many folders that are supported in Vista too, like %Application Data%, %Local, Application Data% etc.
JTMoleBoxed wrote:With regard to using drag and drop for the purpose of populating the "Virtual Box files" list, I run into a situation that seems like it will cause a problem. To continue with the previous example, I can successfully drag the folders "Program Files\Target app" and "ProgramData\Target app" into the files window, where they show up as subfolders of %DEFAULT FOLDER%. However, the files list does not show the full path (as it exists on the HD) to those folders. How can EVB find the files to pack without the full path name?
If you double click on a file (or right click - Properties dialog), you will see the properties of this file, it's virtual local and location in the real file system. These settings are being saved to project file and are used while packing.
JTMoleBoxed wrote:My next question involves the situation where the target app writes entries in the Registry. That is the situation with almost every application that runs under Windows, except those designed to be portable. Therefore, I'm confused about why there is a selectable option to "enable Registry virtualization," since most apps will fail to run if they don't find the Registry keys that they expect to have been created on installation. Shouldn't this option always be enabled?
That's very simple. Not all applications write something in registry while installation. Saying more, very rare applications do that, or, at least, this does not much matter if the registry value was created while installation or no.
You are right, registry virtualization should be enabled for portable applications. But in some cases, programs requires to save some settings to the real registry. In this case, registry virtualization should be disabled.
Registry virtualization is also very useful for registering of ActiveX/COM components without administrator privileges.
On a related point, if the options to "enable Registry virtualization" and "allow writing to the virtual registry" are NOT enabled, will the target app write values to the "real" registry when run?
Yes, sure, it will write to real registry.
Finally, under the "Registry" tab, I notice that EVB does not identify the keys that the target application needs/uses when it runs. I had hoped that it would include technology similar to that found in uninstallers such as Total Uninstall and Full Uninstall, that can make such an identification. Without such automatic detection, there seems to be no alternative to manually creating entries for every key, value, and data value created by the target app when it is installed manually. Since an installed app frequently will create dozens of Registry entries, the time involved in recreating those entries, even using copy-and-paste from a REG file, could be enormous. Am I missing something? Is there a simpler way?
There are plans to make an ability to import registry keys from REG file, but nothing more.
As I wrote, imho, it is not well developed/designed application, if it does work if some registry values were not created while installation. Usually, if there are no such registry keys/values, program simply re-create them. And if so, you do not need to add custom registry keys, just enable registry virtualization.