If there’s ever a great example of the benefits of application virtualisation it can often be found in the little things.
One of the guys in our team has been sequencing Volo View, which isn’t a particularly well behaved piece of software to begin with. It has a menu option that launches Windows Explorer to view some config files and when run under Terminal Services, this fails to launch Explorer.
Rather than use the ShellExecute API to execute Explorer, it appears that the application is using GetWindowsDirectory instead, then appending EXPLORER.EXE to the end of the returned folder name and attempting to launch the Explorer window.
If you’ve been working with Terminal Server for any length of time, you might know that when the GetWindowsDirectory API is called under Terminal Server, the users’ home directory is returned instead of the real Windows directory. Of course EXPLORER.EXE doesn’t live there and thus the application fails to find it.
Fortunately there’s a few application compatibility tricks built into Terminal Server that we can take advantage of to work around issues like this. To fix this issue we can implement a registry value to modify this behaviour for this application. To help Volo View out, we can implement this registry value so that Windows will return the real folder when GetWindowsDirectory is called:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\VPLT\Flags=dword:00000408
The benefit that application virtualisation brings to our toolset (and this is probably not a SoftGrid exclusive), is that we can implement this registry value within the SoftGrid bubble. No changes are required on the Terminal Server itself, instead the fix follows the application where ever it is executed. Very cool.