MSIX - The New Land Registry System [Part 1]

In this blog series, I am penning down very crucial technical issues which lead to MSIX using a land registry system's analogy. Yeah, I know this sounds silly but I like comparing technology with day-to-day systems as the human brain's logic always remains the same. In this first post (part 1), we will discuss the issues with old style MSIs which lead to a new way of containerizing applications. In my next post (part 2), we will explore what challenges this new approach possessed and how it eventually evolved into MSIX.

As I posted in my previous blog, my company has already announced its support for the future Windows installer format MSIX. My job is to see what will this (currently not-so-familiar format) look like in future and how Cloudhouse's products can compliment MSIX. For next few weeks, I'll be digging into MSIX details as my "day job"; and updating generic notes here as my "Sunday morning job". As of today, its very early days for MSIX with hardly any detailed document available, but the source code has been released recently.

The thumb rule of the trading world is that the historic patterns give a clue to the stock's future projections. Same goes for mainline software (like the operating system code and its key components). Such software evolves over a period of time; very rarely are they totally rewritten from the scratch. So, lets first dig into its past and see how Microsoft's installation/deployment mechanisms have evolved over time.

MSI - The Pre Land Registry Era

Let's first understand the MSI Era with an analogy. Thousands of years ago when there wasn't any land registry system in place, people could occupy land and start building their property anywhere they feel like (similar to MSIs creating files and registries anywhere on the filesystem). In those days, there wasn't any controlling authority to regularise the property allocation (similar to that of the operating system not aware/controlling the locations where MSIs installed their resources). This would have had serious security implications as anyone could intrude and use other's property (just like the "DLL hell", where multiple applications use the DLLs created by an application). Finally, when the landlord died, his belongings still remained in place. This is the MSI uninstallation issue. When you uninstall an application, it might still leave its resources behind. And most importantly, as these resources (like DLLs, registries etc.) were shared by multiple applications as soon as you uninstall/upgrade them, other applications break. This was a massive issue! MASSIVE!

App-V - Mail Redirection

To remediate this very issue of "MSI Spill", application virtualization techniques came into existence. Products like ThinApp, SoftGrid (which was later acquired by Microsoft and rebranded as App-V) used a trick to "lie" to the application. 

Let's take another analogy here, the "Mail Redirection System". When you move your house, your new address may not be updated immediately with all the organizations (like the bank, doctor's clinic, kid's school etc.). As an intermediate stage, you can setup mail redirection service with the Postal authorities so that whenever there is a mail addressed to your old house, it will be delivered to your new house instead. That's broadly what application virtualization does!

For instance, when an MSI installs a software, App-V creates an application package by tracking all the file/registry activities performed by the MSI and redirects the calls to a different location. Say for example MSI created a file in "C:\OrigPath", it actually gets created in "C:\VirtualPath" instead. When the application runs, it queries the file with original path "C:\OrigPath\A.txt" which is redirected to the new location i.e. "C:\VirtualPath\A.txt" by App-V drivers. Hence the application gets what it wants, but internally it is a different path. You might call it lying, illusion, redirection or whatever; that's what is application virtualization. This generates a neat application package without any "MSI spill" as every application gets a place for itself and the operating system drivers (App-V drivers in this case) keep track of the application's resources. This solves the DLL hell issues and also cleans all the resources when the application is uninstalled. 

AppModel - Laying the Groundwork

To overcome the old style MSI spill, Microsoft took a step to incorporate application virtualization type of technique in the operating system and defined a set of rules which all the applications should adhere to. This was the motive behind "AppModel". A team of experts (few from SoftGrid) started looking at the new design of how future Windows applications should look like. Their findings were incorporated in Windows 8 in the form of a new format called AppX. And in Windows 10, it became the defacto standard for natively installed applications. For example on Win10, if you browse to "C:\Windows\SystemApps" you will find few AppX packages installed on your system. MS Office's  AppX package would be in "C:\Program Files\Microsoft Office". All the Windows store or UWP applications adhere to AppX standards. This is all good, but any major change comes with its own complications. In development terminology, it is the "Technical Debt" which Microsoft had to pay for years of app development in the MSI era.

In the interest of keeping this blog short, I'll continue this story in my subsequent post (part 2).  Here is a sneak peek of my next post :

• AppX - The Land Registry System
• The Rebellion!
• Mission Project C - The Cops
• MSIX - Bringing it all together!

How can there be a new system in place without any rebellion? Which were these rebelling applications? How did "the cops" try to bring them to the new system? What went wrong? Where did the cops fail? Finally, what led to MSIX?

If these questions arouse curiosity, then wait for my next post in Tech Talk section on Part2. Stay tuned!

Priya Saxena.