Intro to Compatibility Containers – Part 2
In this blog series I would like to give an introduction to Compatibility Containers and will cover the following topics:
- Creating Containers
- Architecture (this blog)
- Redirection (upcoming)
- Updating Containers (upcoming)
- Troubleshooting Containers (upcoming)
This is Part 2 in a series of blog post title “Intro to Compatibility Containers”.
In part 1 we started with Creating a Container and ended up with a Containerized version of my favourite application, Total Commander.
I created the Container in
C:\Output and if we open this in Explorer we will see 3 folders:
The ProgData folder contains all the files and folders that were captured during installation, including the ones that were excluded from the Container.
The RegistryEditing folder contains all of the registry keys and values captured during installation.
As we will see in the “Updating Containers” Part (upcoming), this is a huge advantage as it makes it easier to include missing files, folders or registry keys later on without capturing the installation again!
The Container folder contains the actual Container and all required files to run the container.
This means that the Container is in essence a portable executable that can be placed an run from anywhere and is not dependant on an Agent, Deployment Server or Service.
I think this is huge advantage over Virtualization Technologies: Cloudhouse does not require or use Kernel Mode drivers, Agents or Services . This means we do not require any changes to your images or (virtual) machines.
So let’s have a more detailed look at what’s in the Container folder (I will describe the most important files):
AppAcceleratorV.exe is the Container engine which handles (child) process launch, applies compatibility fixes and redirections. It’s configuration is stored in AppAcceleratorV.clc.
Typical things that are configured in the AppAcceleratorV.clc file are Logging and Feature Flags and which other configuration files are Included. Let’s have a look at the contents of this file in my Total Commander example:
<AAV PackageId="Total_Commander_2468"> <Includes> <Include>Redirections.xml</Include> </Includes> <!-- <Excludes> <Exclude>SomeExecutable.exe</Exclude> </Excludes>--> <!-- <Detaches> <Detach>SomeExecutable.exe</Detach> </Detaches>--> <!-- <Features> <Feature>Service</Feature> <Feature>HandleInvalidHandle</Feature> <Feature>WinVerifyTrust</Feature> <Feature>NotWow64Process</Feature> <Feature>HookCoCreateInstance</Feature> <Feature>HookWinsockAPIs</Feature> <Feature>HookKernelObjects</Feature> <Feature>CitrixRemoteAppRuntimeWithUniqueMutexAndEvent</Feature> <Feature>LocalMappedObjectShim</Feature> <Feature>DEPOptOut</Feature> </Features> --> <Events> <Start>Cloudhouse.Container.Usage.exe /usageId:%UsageId% /event:RunStarted</Start> <Exit>Cloudhouse.Container.Usage.exe /usageId:%UsageId% /event:RunStopped</Exit> </Events> </AAV>
By default there will be one file included which is Redirections.xml, this file contains file and folder Redirections but the Include section can also be used to configure a Container to depend on another Container.
Redirections can not only include files, folders and registry keys/values but a unique capabilty of Cloudhouse is that we can also redirect Windows API calls or parameters. An example would be to replace arguments passed on the commandline.
The Features section has been commented out meaning that no special features (shims) were required for this application. Examples of Feature Flag usage are Run multiple instances of Skype for Business concurrently and Cloudhouse for Google Earth on XenApp.
AppAcceleratorV32.dll is a helper file that is loaded into child processes, Containers with 64 bit applications will also include a 64 bit version (AppAcceleratorV64.dll).
AppRegistry.xml is an xml file containing the initial registry keys and values for the container, the fact that this is an xml file makes editing (e.g. adding a required registry key/value) very easy.
In a similar way, EnvironmentVariables.xml contains the Environment variables for the Container and FileAssocciations.xml contains the File Associations (extensions) which should be associated with the Container.
Programs.xml defines the entry points for the Container, this will be filled with the items detected during capture such as Start Menu and Desktop Shortcuts. It will default to the main executable as selected in the Auto Packager.
In my case the contents are:
<?xml version="1.0"?> <Programs xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Program> <RunCondition>Initial</RunCondition> <ProcessWindowStyle>Normal</ProcessWindowStyle> <Path>%DefaultDir%\AppAcceleratorV.exe</Path> <Args>/f "%DefaultDir%\ProgData\totalcmd\TOTALCMD.EXE"</Args> <WorkingDirectory /> <WaitCondition TimeoutInSeconds="0">None</WaitCondition> </Program> <Program> <RunCondition>FileArgs</RunCondition> <ProcessWindowStyle>Normal</ProcessWindowStyle> <Path>%DefaultDir%\AppAcceleratorV.exe</Path> <Args>%FILEARGS%</Args> <WorkingDirectory /> <WaitCondition TimeoutInSeconds="0">None</WaitCondition> </Program> </Programs>
If you start Cloudhouse.Container.Run.exe it will launch the default entry point as defined in Programs.xml. This makes it easy to launch the main entrypoint of the Container directly, without even Deploying the Container.
Using commandline arguments it’s possible to test the other entry points during packaging.
The last file is Cloudhouse.Container.Deployment.exe which deploys the Container from a file share, or local directory, that the executable resides in to the server or desktop the command is executed from.
This means that you can leverage your existing deployment tooling such as SCCM to deploy a Container whereby our Deployment tool takes care of creating Start Menu items, registering File Associations etcetera.
Here is the Deployment for my Total Commander example:
If we compare Cloudhouse Compatibility Containers to traditional Application Virtualization such as App-V the most striking difference is that we do not use any Drivers, Kernel Mode components, Agents or Services and therefore require no changes to your images.
Further more we do change the way you deploy and manage Applications: Containers can be deployment with existing tools such as SCCM, can be managed with your favourite UEM (e.g. RES, AppSense, Citrix WEM or VMware User Environment Manager).
This means we do not change the way you currently work and do not introduce extra dependecies.
In the next blog post I will go into details about Redirection: what kind of Redirections are possible? How does it work and where is the configuration stored.
Migrate ALL applications to Amazon AppStream 2.0 and AWS WorkSpaces
Migrate ALL your desktop applications to Amazon Workspaces or Amazon AppStream 2.0 with Cloudhouse.
The Magic of Compound Application Virtualization
I am Priya Saxena, a supermom, virtualization enthusiast and a developer by heart. I started my career 11 years ago as a passionate engineering graduate
Legacy Apps: The Boring and Dirty Problem You Don’t Want to Deal With
There’s this boring, dirty, problem most organisations have and it has to do with legacy apps. Apps that were created over 10 years ago to solve a specific – at...