Q:
Craig asked: Can you have App 8.0 and App 10.0 running at the same time, even if both apps use the exact same EXEs?

A:
Well, Craig, in most cases, yes – as long as both versions of the app are located at different paths (otherwise you would not be able to make two different shortcuts -- one for each version).

We have found at least one case -- the Adobe Acrobat family -- where if a version is already running, it will just open another window of that version rather than allowing you to start up a different version. We don't know why -- probably to prevent people from causing problems. SVS didn't exist when they built in that feature. ;) Read about the workaround here.

Everything else in our test suite (including MS Office apps from '97-2003) allows simultaneous instances of different versions.

Q:
Julie queried: The documentation indicates that the Virtual Software has basically "no overhead". I'm thinking that there is probably a disk space factor, at least. Is this true and, if so, can you tell me an approximate size for each virtual layer? Are we talking MB or KB or GB? Also, how about memory considerations?

A:
Good question, Julie! Apps in layers consume the same amount of disk space as if conventionally installed, with perhaps a small additional amount for duplicate files which would be shared files in the conventional world. No additional RAM required. Even fully loaded, our filter driver consumes less than 1 MB of kernel memory.

Q:
Steve asked: Will there be a release of Software Virtualization for Servers in addition to the solution for clients? If you could please reply at your earliest convenience, I would greatly appreciate it!

A:
Hey Steve, SVS 2.0 is supported on all flavors of Windows 2000, XP and 2003 (except for XP Embedded), when used as a single-user client/workstation or personal computer.

The next release (Lightning) will be supported on servers (including terminal servers). The product will be added to Server Management Suite (at some level TBD) at that time.

Randy Cook gives us some vital info about how SVS interacts with the Windows Registry. If you're faced with editing the registry of a virtualized app (shudder) this tip could be a life saver.

If you come to a point in life when you need to tweak the Registry of a virtualized application, you'll want to keep this explanation of how SVS works with registry keys within reach.

The HKEY_CLASSES_ROOT key is a virtual key that Windows creates by combining the data from HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes. When there is a conflict in this data, preference is given to the data contained in HKEY_CURRENT_USER\Software\Classes.

SVS does not store data in the virtual HKEY_CLASSES_ROOT key. Instead it stores it in its real location under either HKEY_CURRENT_USER\Software\Classes or HKEY_LOCAL_MACHINE\Software\Classes. At runtime, Windows reads the SVS data for active layers from these locations and properly renders HKEY_CLASSES_ROOT....