MSIX: Slightly more detail about what might be something huge but probably won't be
Over on his blog, Rob wrote about his guesses for what the still-somewhat-mysterious MSIX means for Windows deployment. We got some details at the Build conference last week. The two most-detailful were
Here are my key takeaways from these presentations.
MSIX: One package format to rule them all
Appx packages today are Open Packaging Conventions Zip files with a manifest. With the (sometimes painful) magic of XML namespaces, a single manifest can cover many different types of apps: Witness the sometimes-significant differences in the manifests of UWP apps and Desktop Bridge apps. And, of course, Zip files let you easily include different sets of files, like the registry hives in Desktop Bridge app packages.
In MSI terms, the tables that make up the MSI database are represented in special “footprint” files, like AppxManifest.xml and additional well-known files, like Registry.dat. Installed files for an MSI package are typically stored in a .cab file, either embedded or stored next to the .msi file. In Appx, the installed files are stored as normal Zip file entries in the .appx file.
The MSIX Packaging SDK – sometimes named just the “MSIX SDK” – contains MIT-licensed code that implements the Appx packaging APIs to build .appx and .appxbundle packages. If you’ve spent any time building Appx packages, you understand that Microsoft open-sourcing this code is a pretty big deal, if only because the error codes from the API functions are truly terrible and now we can debug the code to better understand error states.
On a slightly more serious note, the MSIX packaging API has several interesting features, like supporting signing and the package “block map,” which is what makes it possible to do differential downloads of package contents.
So that’s all cool but at the end of the day, what we heard about the MSIX format – being cross-platform and available on Windows 7, for example – is essentially saying that Zip files make a good package format because they can contain files (including manifests) and they work everywhere. Well, yes, that’s true but not exactly an earth-shattering pronouncement, is it? A file format is necessary, sure, but what matters is the engine the interprets the contents.
MSIX: One engine to rule them all
MSIX packages, like UWP Appx packages, Desktop Bridge Appx packages, and even MSI packages, are just data. It takes an engine to open a package, read its metadata (manifests or tables and rows), and apply it to the machine.
At Windows Developer Day, MSIX was described as “.appx + MSI.” The mention of “MSI,” combined with repeated mentions of “containers” and tidbits like “Supports all Windows applications” led me almost immediately to assume that MSIX included the use of App-V.
Nine years ago, I joined the App-V team, then in Cambridge (the one in the United States, not the original. One of the big reasons was that I saw a lot of potential in the App-V container model of delivering software. Bringing that capability to ISVs would be a great way to make better installers for everybody. Unfortunately, that didn’t happen while I was there and hasn’t since. But maybe that was about to change…
App-V already supports Win32 features like services that Desktop Bridge does not support (today). App-V already has extensive support for enterprise IT management. App-V has a long history of supporting virtualization of apps that weren’t designed for it.
I’d so thoroughly convinced myself App-V was part of MSIX that I started writing a blog post to parallel Rob’s. Luckily, I didn’t finish it because MSIX is not App-V. There was no mention of App-V at Build except for how it wasn’t going to be deprecated…yet. Naturally, I was disappointed…mostly at having guessed wrong.
Everything discussed at Build points to the engine underlying MSIX on Windows being Desktop Bridge. However, remember that Microsoft has enhanced Desktop Bridge functionality with every release of Windows 10 since the Bridge was introduced in Anniversary Update. So even if today Desktop Bridge doesn’t support some Win32 feature doesn’t mean it never will.
But it also means that MSIX isn’t a revolutionary new engine (or old engine, for that matter) with unexpected power. And unless someone writes such an engine, MSIX isn’t going to be a “thing” on Windows 7. You can build MSIX packages on Windows 7 (and Windows 8.1 – did everyone forget about that one?) but with no runtime engine, they’re just Zip files.
MSIX: Welcome to the evolution
If you found the idea of “.appx + MSI” compelling, well, congratulations, you’re quite the nerd. (Join the club. We have jackets.) The reality, at least as described in Build talks, paints MSIX mostly as a rebranding of Desktop Bridge. That’s not a bad thing but I was expecting more given the buildup.
We’ll likely see more details – maybe we’ll see some exciting ones? – leading up to the next release of Windows 10 later this year.