Introduction to Modern Applications

Modern, and other, Application Forms

Software has traditionally been provided to you from internal and external software developers in one of the traditional forms of EXE and MSI installers. Organizations prepare the application, customizing both the form of delivery and the contents in ways that improve efficiencies and end-user satisfaction.

Organizations that have moved to modern forms have most likely done so on their own. We see that this is starting to change with MSIX, as vendors appear to take interest in providing future applications in this modern format. But, even when delivered in the modern format, organizations will still need to process and configure the application for delivery.

The modern form includes technologies such as Application Virtualization, Application Layering, and Application Containers (where MSIX falls).

The Purpose of Packaging

The reason we package an application is to simplify the life of the end-user, shielding them from things that they don’t need to be involved with. Sometimes, it is a convenient way to hide aspects from the end-user, such as licensing keys or back-end infrastructure details that they do not need to know. Some of the benefits of application packaging for companies include:

• The customization of general-purpose applications to fit the needs of the organization.
• Increased productivity of end-users - The majority of which are not IT Pros.
• A wider applicant pool for a given position (they don’t need to be computer experts but know how to use the app),
• Increased security of its systems by reducing the need or use for admin credentials.

Ultimately, the purpose of packaging comes down to reducing costs. While certainly there are costs associated with the packaging process, these are outweighed by the cost savings that come from simplifying a process that allows end-users to focus on the tasks they are being paid for - that don't necessarily include installing software and its complications.

Handling Dependent Reusable Components

More often than not, Application packages include dlls components that are reusable from other parties. The most common are the Microsoft Visual C++ runtime components (although there are many other sources as well).

In a native installation, these components may be installed either into system locations or in the same package folder with the application. In the application repackaging industry, there are two different schools of thought on how to handle these components.

These two approaches are as follows:

• One is to identify dependencies, separating them for independent delivery, and removing them from the repackaged app.
• The second is to keep them within the repackaged app.

Although some organizations believe their approach is the right one to use, the truth is that: there's not a one-size-fits-all method that works for all organizations, andusing only one approach may not be suitable for all situations within any organization.

Traditionally, we worried about version conflicts when these components were written into shared areas, a concept referred to as “dll hell”, where installing one new application might break any of the others on a system and you wouldn’t know unless you test all of them.

Today, different versions for most of these components are installed into different file locations, even in a system installation, so it is less of an issue. The problem now tends to be with older application installers that add known flawed shared components that lack fixes for known security vulnerabilities, and we want to ensure these are always patched.

Organizations using Configuration Manager to deploy apps repackaged as MSIs usually prefer the separation approach. While organizations repackaging for an isolation environment, such as App-V or MSIX tend to take the other approach; which takes much less work and it is less unlikely for vulnerabilities to be exploited, especially in an isolated environment.

We're not here to guide you through what the best approach is for you. But, to make you aware of these choices we recommend that you follow the approach(es) used by your organization. We can also suggest that as you gain more experience and changes occur in the technologies we use, the so-called “correct” approach today may not be so “correct” in the future.

The Techniques of Application Packaging

There are three general techniques used in application packaging.

• Automation. This encompasses techniques that do not alter the vendor installer directly but are used to apply it. This includes the use of scripts wrapping the application installer, as well as the use of tools that provide additional files such as MST Transforms.
• Conversion. Converting an installer file from one form into a new form. This includes the use of MSI editors that produce modified MSI files and format conversions (such as from MSI to either App-V or MSIX) that do not require an installation capture of the installer.
• Capture/Re-packaging. Performing the installation and customization of an application within a monitored environment to capture the changes and produce a customized package.

As someone responsible for application packaging, you will probably need to use a variety of these techniques over time. Your organization will likely have selected a small subset of all of the available first and third-party tools to help make packaging activities consistent and reliable. The MSIX Packaging Fundamentals book will provide you the knowledge that you need to succeed no matter what techniques or tools are used.

The Traditional Software Installer

Software is generally provided in the form of an installer. The installation is primarily a combination of writing files and entries into the Windows file system, often utilizing system utilities to perform registration activities.

Most of the software you work with comes in the form of an EXE or MSI based installer. The MSI installer is usually preferred for packaging as it uses a set of tables that can be easily examined and manipulated, while the EXE-based installer tends to be less transparent. Sometimes the EXE-based installer embeds an MSI that is used as part of the process. But ultimately, the EXE-based installers and any custom actions included in an MSI are binary “black boxes” that we can only understand by watching what they do.

The purpose of the vendor installer is not only to place the appropriate components in place on the system but also to configure the application for the user. Often, this involves some decision-making from the installer's side based on the environment it is being installed on. This adaptation to the environment could potentially include examining the machine, the OS, the end-user, as well as other software on the machine, and even the surrounding network including other servers or services.

The role of the packager and packaging software is to end up with a generic package that may then be deployed to any system with organization-wide customized defaults. Special care is required when the techniques used include a repackaging process. Issues can arise in repackaging due to the unintentional capture of unwanted components or configurations by the installer that are specific to the capture machine.

The goal of any repackaging process that you are involved with should be to produce a clean and customized package that will work on any intended system, along with appropriate documentation that would allow that same package to be reproduced in the future.

On Spoofs, Redirections, and Overlays

Virtualization, Layering, and Containerization all employ similar techniques to achieve their goals. The details of how and when these techniques are used vary, but first, you need to have an understanding of the basic techniques that they employ.

We will refer to them as Spoofs, Redirections, and Overlays. In essence, Redirections are a specific form of Spoof, and Overlays are an application of redirections, so technically, we could just use a single term - but as we will see, there is value in separating them out into three terms.

Spoofs

In reality, everything done in modern application runtimes falls under the “spoof” category. We can define a spoof as something that intercepts an action (function call, for example) and alters the requested action or result. In MSIX terms, a Package Support Framework shim, which intercepts a Windows API call and modifies it, implements various kinds of spoofs.

Modern application runtimes routinely implement spoofs for file redirection, changing a COM GUID, or renaming a semaphore for isolation purposes.

Redirection

A particularly popular form of spoof is the redirection spoof. Used against calls to the file system or registry, it takes a filepath or registry key path as requested by the application and in essence, it says: “I know you asked for this, but I’m going to give you this other thing instead”.

Fundamentally, this allows for traditional code to not know that it is not running in a modern environment. It might think that it is installed to the default “C:\Program Files\VendorName” folder, while all of the files are located wherever the modern app runtime puts them.

A common use of Redirection used in several modern systems involves a folder called VFS (for Virtual File System) along with subfolders with specific names that refer to an equivalent “un-redirected” location. Thus “VFS\ProgramFIlesX64\VendorName” equates to the “C:\Program Files\VendorName” folder that the app might request.

Layers

Layers are a visual analogy used to describe the concept of how the modern runtime systems act.

The visualization we use to describe the layering concept is called panes of glass, whereby a piece of software, depicted in the image as an Application, sees the system through a series of glass panes. When items are placed on a glass pane, they can add to, or replace parts of what the application would see without them.

In application runtime systems, we usually think of a model such as the one shown above, where the application is working with three layers. Drawn horizontally, the rightmost layer is the operating system with its file system and registry. Just left of that is the application layer, containing additional and/or replacement files and registry entries. The application layer is immutable, meaning that the runtime system does not allow changes to occur in that layer when the user runs the application. Instead, changes to the application are made to the third layer, shown left of it. We can call this third layer: the user settings and data layer for that application.

This makes a nice visual, but of course, things are always more complicated! Items written to the upper layer can be used only by the application, and often we want settings and data to be usable outside of this application. So while some information needs to be written to that layer, other pieces need to be allowed to be written to system locations, such as the Documents folder, cloud sharing folders, home drives, and network shares. As a general rule, the runtime systems generally use the presence of items in the application layer to make this determination.

The layering concept is implemented by using redirections. Redirections may be implemented in the runtime as user mode intercepts (added to the application process by dll injection) or kernel filter drivers. Some runtime systems employ both techniques in different areas. In a redirection, the request by an application to perform an operation, such as opening a file with a certain file path, is examined and the request is redirected to a different location, which we think of like one of those panes of glass. In reality, this is just a different location on the system, but it is easier to just think of it as that glass pane.

Combining these techniques to solve application challenges

While the effect of redirecting a file or registry call is simply giving the application the best location choice, internally it is much more complicated. Consider the following case:

• The OS has a folder with some files in it.
• The application layer has additional files in its overlay folder.
• When running the application, the end-user added a new file to that folder or modified an existing one, from the third layer.
• If the application then makes a request to find files in that folder, the redirection software must query folders on all three layers to form the query reply.

Such a situation requires a combination of spoofing, redirection, and layering and is just one example of how modernizing applications alters what the application sees and does.

Moving Towards MSIX

Microsoft is making a major commitment with MSIX. In the future we expect MSIX to become the preferred format for software vendors to deliver applications to their customers, overtaking the ubiquitous MSI during this decade. For the software vendors, it is about staying current in their products so that they may take advantage of the new OS features that will only become possible when writing code that runs inside the MSIX container. For Microsoft customers, MSIX offers the promise of simpler application customizations, secure and safe installs and more stability for the end user.

MSIX is evolving as it is being delivered. In the remaining chapters of this book we will focus on the fundamental technology as it stands today, look at currently available tooling. After that, we then dive into both packaging and deployment fundamentals which should provide you with a complete picture to work from for the future.