Virtualization

The closest SVS comes to "Dynamic Path Relocation" is that it does not move files but uses SVS variables such as enclosed in square brackets ([]). So what it does describe is that the SVS filter driver will redirect to the (dynamic) value of the SVS variable which will be the value of the environment variable. This makes SVS handle different versions and languages of windows.

The "View Variables used in a Layer" topic describes abit of this.
http://juice.altiris.com/content/softwarevirtualization.pdf

Cheers!

/Kim

By default (out of the box), SoftGrid runs on Windows 2000 through Vista - desktop or server - and it can be run on beta-versions of future OSs (i.e. Windows Server 2008) by deleting all specific OS XMLs tag values within the OSD files (this is tested & proven, but no claim of MS support has been made).

Who still wants to support NT anyways? ;^)

I'm no expert on Side-by-side Assemblies (aka WinSxS) but was abit confused why Thinstall stated the bellow:
If you capture an application that uses SxS DLLs on NT/2k/XP/w2k3 it will install SxS DLLs to a path location differently than when installed on Vista. Thinstall dynamically moves these SxS during the application startup if the platform has changed.

Couldn't find any reference about Windows Vista and WinSxS regarding different location of the DLL as stated above.
The only thing I found was that due to WinSxS is part of Windows Resource Protection only the TrustedInstaller account are allowed to modify the WinSxS folder.

Anyone?

Thanks guys. It just seemed to me that if you really could create a package that would work regardless of what version of Windows you were targeting-- that would be a [another] very strong benefit of application virtualization. It has also been suggested that you could address Vista compatibility issues this way-- get your virtual package running on XP and then just take it to Vista where it is "dynamically" supported.

Has anyone actually had an application that would not run in Vista, but packaged as a virtual application, did work as a virtual package created on XP?

I can't answer your question on apps not working on Vista in a virtual mode, but I have a thought on MS's acquisition of Softricity & Vista. Maybe they were planning for the future (at the time) & anticipating compatibility problems? ;^)

Has anyone actually had an application that would not run in Vista, but packaged as a virtual application, did work as a virtual package created on XP?
I have no answer on that as in Sweden virtualization of applications isn't that big yet.

Creating a package, wheither it's virtual or not, on a higher version then it's supposed to be used on has the same problem/rules. Doing a capture/install in such scenario could prevent the application to work as the installation may not install/overwrite existing files with higher versions and therefore not include that file in the package. You also have to address conditions on specific versions, ex (Windows Installer) components conditioned to only install on certain version of windows.

So a general rule as always is to create the virtual package (and MSI packages) on the lowest operating system in the environment the application should be used on.

I think virtualization does allow for applications to be more portable across environments and operating systems but the gain isn't huge. I think what virtualization gives you is the ability to compensate for a poorly written installer. A well written MSI should work just fine across multiple operating systems but repackaged installers usually have issues when the target platform varies because there isn't enough installer logic to compensate for the changes.

The note on Side-By-Side assembles is interesting because the support for Side-By-Side using SoftGrid still seems to be a bit of a hit and miss feature. I've also seen some issues with Wise Package Studio properly setup capturing Side-By-Side assembles but I don't know if that applies to SVS.

One issue why an application may fail on Vista could be due to (incorrect/not supported) higher DLL versions (already existing) which a regular installation would not overwrite and therefore not capture. If you virtualize this to include these lower DLLs on another windows vesion, lets say windows xp, the virtual application will use these (correct DLL version) instead preventing the application from failing. Due to SVS default priority order you may have to play with setting different priority order for the layer.

I've seen users report problems with Side-By-Side assemblies but that is often due to wrong order of installation. .NET Framework must be installed before WPS/WFWI or WIS for it to recognized. If this is the case doing a repair should solve the problem.

Regarding SVS and Side-By-Side assemblies it may differ for a single or global capture.
I've read in some threads at the Altiris forum that there should not be any issues of this or GAC but not tested this myself.

ORIGINAL: AngelD

One issue why an application may fail on Vista could be due to (incorrect/not supported) higher DLL versions (already existing) which a regular installation would not overwrite and therefore not capture. If you virtualize this to include these lower DLLs on another windows vesion, lets say windows xp, the virtual application will use these (correct DLL version) instead preventing the application from failing. Due to SVS default priority order you may have to play with setting different priority order for the layer.


I've seen limited success with this but usually the application I am trying to get working on a newer OS is some old piece of junk that hasn't been updated in the last five years.