Video Screencast Help

SWV 6.1 SDK Guide Part 4: Processes

Created: 31 Jul 2009 • Updated: 29 Jul 2010
Language Translations
Jordan's picture
0 0 Votes
Login to vote

Parts 2 and 3 of the SWV 6.1 SDK Guide covered the new layer management functions introduced in SWV 6.1. In this article I'm going to be covering the API that affect processes running from within a layer, namely Auto Run from Layer and Deactivate on Last Process Exit. These two features have a great synergy and really expand on what you can do with application virtualization and how your end users interact with applications.

Changes to the FSL2 Class

ManagedSVS.cs has several new methods added.

You can download the newest version of the FSL2 Class from the download portal.

Auto Run from Layer

This new features is really an extension of an old SVS feature Run from Layer (also known as Execute from Layer or exec) which runs an application that is not virtualized as if it was. For example, if you exec notepad from a layer the changes you make to any text files will get caught in that layer. Auto Run from Layer takes that concept one step further buy attaching certain processes to a layer and whenever that process runs the layer will activate, if not already active, and exec the process from the layer. An example of this would be attaching notepad to a layer, deactivating the layer, and then launching notepad. The layer will activate, exec notepad from the layer and any changes made by notepad will get captured into the layer.

addAutoRunProcess

public static extern UInt32 addAutoRunProcess
 (
   string fslGUID,
   string pProcess,
   string pParentProcess,
   string pCommandLine
  );

AddAutoRunProcess is one of two methods for adding processes to a layer's Auto Run List and it takes four parameters: a GUID, the process to watch, the parent process, and the command line (if any) for the process being run.

If something is passed into the parent processes parameter then the only time the processes will auto exec from a layer is when it's being launched by that parent process. A quick example of this would be acrobat launching from a web browser. The commandLine parameter is for any switches or parameters that you want to pass into the application as it gets launched.

Both pProcess and pParentProcess need to be the full path to the exe that you're wanting to run.

If you don't have anything you want to be set for ParentProcess or CommandLine pass in a Null (if using C\C++) or the * character (.Net or C\C++).

SetAutoRunProcessList

public static extern UInt32 setAutoRunProcessList
 (
   string fslGUID,
   string pProcess,
   UInt32 cbProcess
  );

Sometimes you want to set more then one process to launch automatically, and while you can call addAutoRunProcess as many times as you want you can also just call setAutoRunProcessList once and pass it in a string, pProcess, of what you want added. Using this API will replace any items that already exist for the layer, so you can use this API to clear a layer of all AutoRunProcesses by passing in an empty string.

The format is pretty simple, a tab character (\t) is used to separate the parent, child and command line arguments and a null character (\0) is used to separate the different items in the list. To close off the list you pass in two null characters at the end (\0\0).

An example would be:

string myProcList="ProcessName\ParentProcessName\CommandLine\0ProcessName2\ParentProcessName2\CommandLine2\0\0";

GetAutoRunProcessList

public static extern UInt32 getAutoRunProcessList
 (
   string fslGUID,
   string pProcess,
   UInt32 cbProcess
 );

GetAutoRunProcessList is pretty straight forward. It grabs the list that's stored in the registry and then returns it in the same format as listed for SetAutoRunProcessList. A tab character (\t) is used to separate the parent, child and command line arguments and a null character (\0) is used to separate the different items in the list and two null characters at the end (\0\0) to close off the list. You'll have to parse through them to read the information you want.

Remember that for the process and parent process you need to pass in the full path to the exe you want to run.

RemoveAutoRunProcess

public static extern UInt32 removeAutoRunProcess
 (
    string fslGUID,
    string pProcess,
    string pParentProcess,
    string pCommandLine
  );

RemoveAutoRunProcess is the last API for this feature. It works similar to AddAutoRunProcess where you pass in a string for each item, process name and path, the parent process name and path and the command line arguments. If you don't have anything you want to pass in for the parent or command line you pass in a Null (if using C\C++) or the * character (.Net or C\C++).

Both pProcess and pParentProcess need to be the full path to the exe that you want to remove.

If you want to remove all the AutoRunProcesses from a layer you need to use SetAutoRunProcessList and pass it in an empty string.

Deactivate on Last Process Exit

The second process related feature added to SWV is Deactivate on Last Process Exit which does pretty much what it says. If this flag is set a layer will automatically deactivate once all processes have ended in the layer. This includes background processes that don't get closed when the main process ends, like adobe updater, as well as services like iPod Service.

SetDeactivateOnLastProcessExit

public static extern UInt32 setDeactivateOnLastProcessExit
  (
    string fslGUID,
    bool bDeactivateOnLastProcess
  );

This rather wordy API takes a GUID and a bool which will set the layers Deactivate on Last Process Exit flag. TRUE if you want the flag set, FALSE if you don't.

QueryDeactivateOnLastProcessExit

public static extern bool queryDeactivateOnLastProcessExit
  (
   string fslGUID
  );

Here you pass in a GUID and it returns TRUE or FALSE if the layer's Deactivate on Last Process Exit flag is set.

Seeing it in Action

In this example I'm calling the different API to set and clear an Auto Run From Layer list. Now I'm just using a preset string for these but you'd probably want to parse in a text file or XML file for setAutoRunProccessList and a command line argument for addAutoRunProcess and removeAutoRunProcess.

FSL2 mySVS = new FSL2();
 StringBuilder myGuid = new StringBuilder(FSL2.MAXIDLEN);
 FSL2.createLayer("testLayer", FSL2.LAYER_TYPE_NORMAL, true, myGuid);
 UInt32 result= FSL2.addAutoRunProcess(myGuid,"C:\\Windows\\System32\\notepad.exe","*","*");
 if (result == 0)
   {
    Console.WriteLine("Notepad set");
    Console.Read();
   }
   else
   {
    Console.WriteLine("Notepad not set");
    return;
   }
 result = FSL2.removeAutoRunProcess(myGuid, "C:\\Windows\\System32\\notepad.exe", "*", "*");
 if (result == 0)
  {
    Console.WriteLine("Notepad removed");
    Console.Read();
  }
  else
  {
    Console.WriteLine("Notepad not removed");
    return;
  }
 string myProcList="ProcessName\tParentProcessName\tCommandLine\0ProcessName2\tParentProcessName2\tCommandLine2\0ProcessName3\tParentProcessName3\tCommandLine3\0\0";
 result = FSL2.setAutoRunProcessList(myGuid.ToString(), myProcList,UInt32.Parse(myProcList.Length.ToString()));
 if (result == 0)
  {
    Console.WriteLine("Process List Set");
    Console.Read();
  }
  else
  {
    Console.WriteLine("Process List not Set");
    return;
  }
 myProcList = "";
 result = FSL2.setAutoRunProcessList(myGuid.ToString(), myProcList, UInt32.Parse(myProcList.Length.ToString()));
 if (result == 0)
   {
    Console.WriteLine("Process List Removed");
    Console.Read();
   }
   else
   {
    Console.WriteLine("Process List not Removed");
    return;
   }

I've added some basic error handling as well as some reads, so the command line pauses. You can check either SVSadmin or the registry to see how each of these API behaves. I didn't pass in the full path to the process in setAutoRunProcessList, to keep the string more readable, so make sure you change this if you want to test to see how the feature works outside of the API.

Conclusion

Auto Run from Layer and Deactivate on Last Process Exit greatly extends a layer's ability to manage how it behaves in relation to the process running inside of it. Both of these features have great synergy with OnEvent Notifications.

In the past four articles I've covered well over half of the new features and API in SWV 6.1 which pretty much leaves Dependent Layers as well as Layer Visibility which will be covered in that order over the next two articles.

Return to the Virtualization SDK Book