Video Screencast Help
Symantec Secure Login will be live on Connect starting February 25. Get the details here.

SWV 6.1 SP4 SDK Guide: Updated Guide to Mounting Registry Hives and Exporting a XPF

Created: 08 Dec 2010 • Updated: 08 Dec 2010 | 2 comments
Language Translations
Jordan's picture
+3 3 Votes
Login to vote

Back when Symantec Workspace Virtualization 6.1 SP1 came out we introduced Registry Hive Mounting as a new feature.  You can read about these changes in either the previous SDK guide about this or in a non-developer targeting article here on connect.  This article will cover the new hive mounting as well as how to export in the new XPF format.

Changes to the FSL2 Class

Two new functions have been added to ManagedSVS.cs

New types have been added to SVSConst.cs

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

Hive Mounting

The big change to know about is FSL2SubLayerEditStart and FSL2SubLayerEditStop have been deprecated as of SWV 6.1 SP4 and will be removed from the SDK in the next Release (SWV 6.1 SP6) and have been replaced with VzStartLayerEdit and VzStopLayerEdit. 

While these new methods do something quite different behind the scenes their use in the SDK is very similar but simpler, you no longer have to deal with a registry handle that you have to track, and more importantly cause problems if you lose, and instead you just need to pass in a GUID and a flag to get the desired effect.

Because someone might need to develop for older versions I am leaving them in the SDK class but they shouldn’t be used unless you’re using the correct version of SWV.

Detecting Version

The problematic issue with this change is now there are three different versions of SWV’s registry editing code out there and you’ll need to detect the version of SWV being used if you’re planning on targeting more than one type.  The three types are:

  1. Non-hive mounting that was in SVS 2.1 and SWV 6.1 MP1. Basically pre 6.1.5000 builds
  2. Old Hive mounting that was in SVW 6.1 SP1 (6.1.5000) through SWV 6.1 SP4 (6.1.1575)
  3. New Hive mounting from SWV 6.1 SP4 (6.1.1575) forward.

I covered extensively how to detect what version of SWV or SVS that was installed in Part One of the SWV 6.1 SDK Guide, you can use the function GetDriverVersion to determine what the behavior of a specific API is, in the case of patch, or if an API is available or not. For SP1 this is very simple, anything post build 6.1.5000 is SP1, so you just need to check that version1 is 6, version2 is 1 and version3 is greater than 5000. If version3 is less than 5000 then you're using MP1.  Starting with SP6 we’re incrementing version2 with each Service Pack so SP6 will have a 3 (6.3.xxxx) and the next Service Pack with have a 4 (6.4.xxxx) for easier version detection.


publicstatic extern UInt32 vzStartLayerEdit 
    string fslGUID,
    UInt32 flags

This is a very straight forward function.  You pass in the GUID of the layer who’s hive you want to mount and then you pass in the VZ_MOUNT_EDIT flag for the flags parameter.


 public static extern UInt32 vzStopLayerEdit
    string fslGUID,
    UInt32 flags 

Just like vzStartLayerEdit this is very simple, you pass in the GUID for the hive you want to dismount and then the flag VZ_DISMOUNT_EDIT.

Exporting a XPF

As of SWV 6.1 SP4 the default export format was switched from VSA to XPF.  The main difference to know about these two formats is that XPFs use a faster Zip library and can be streamed with no additional work as long as the XPF meets the following requirements:

  1. Contains an EXE
  2. Contains a shortcut to said EXE
  3. The shortcut isn’t an Advertised Shortcut.

If your layer doesn’t meet these requirements then you’ll have to use Symantec’s Wise Virtual Composer to create you layer as it will add dummy shortcuts and EXEs and clean up Advertised Shortcuts when you export via it.

Exporting a XPF isn’t much different than a VSA but you’ll need to switch from FSL2Export to FSL2ExportEX, which is covered briefly in Part 3 of the SVS SDK guide so I’ll cover it here more extensively since people will actually need to be using it.


publicstatic extern UInt32 exportEx
    string fslGUID,
    string archivePath,
    ref IMP_EXP_V1 pUserData,
    UInt32 structureVersion,
    UInt32 flags

This is almost exactly the same as FSL2Export.  You’ll pass in your layer GUID, the path to where you want to save the XPF, your callback function (covered extensively in the above mentioned SVS SDK Guide Part 3), your user data information, and version.  The difference is the flags parameter which is how you configure what the export is doing.

Like any of the flags parameters in the SWV SDK these are simple integers that you add together to when you pass them in, but to make it so you don’t have to remember the numerical values we have constants, called types, they you can use.

The main types for ExportEx are:

LAYER_REPLACE_IF_EXISTS – Pretty self explanatory

STRIP_SID_INFO_FROM_LAYER – using this flag causes the exported package to contain an empty RW Sub-layer

FSL2_EXPORT_XPF—tells ExportEX to export a XPF, if not used a VSA is exported instead.

Seeing it in Action

Here’s a sample ExportEX code block

 FSL2 mySVS = new FSL2();
 StringBuilder myGuid = new StringBuilder(FSL2.MAXIDLEN);
 UInt32 result = FSL2.createLayer("CreateTest", FSL2.LAYER_TYPE_NORMAL, true, myGuid);
 result = FSL2.exportEx(myGuid.ToString(), "C:\\APIexport.xpf", impExpStatus, ref mySVS.pUserData, FSL2.LAYER_TYPE_NORMAL, FSL2.FSL2_EXPORT_XPF + FSL2.STRIP_SID_INFO_FROM_LAYER + FSL2.LAYER_REPLACE_IF_EXISTS);
 if (result == 0)
   Console.WriteLine("Pacakge successfully Exported.");
   Console.WriteLine("Error exporting layer.  Error Code "+result.ToString());

  publicstatic void impExpStatus(FSL2.IMP_EXP_V1 RTInfoFunc)
     // callback code

Return to the Virtualization SDK Book

Comments 2 CommentsJump to latest comment

Kel's picture

Thanks Jordan, a great series of articles and very useful.

Login to vote