- They're zips (sorta, but you can't make them with any existing zip library)
- They can contain VFS overlays for system directories. Files placed inside the package under the VFS directory will appear at runtime as if they are installed to c:\Windows\System32 and other well known locations, but only for apps within that package. This is built using an equivalent of unionfs called bindflt.
- Apps run inside "app containers" which are at the lower levels composed of job objects and other kernel features. App containers are the basis of all sandboxing on Windows and are the closest equivalent of cgroups.
- Writes to the user's home directory are transparently redirected to a separate directory specific to that package. This allows data to be cleaned on uninstall.
- You can express various integration points in a declarative manifest file, install/uninstall/download them from the CLI, and individual packages have update feeds a bit like a Docker repository.
There are some differences:
- MSIX is designed for desktop apps, not servers.
- There's no concept of layering like Docker has.
- A Docker repository is a relatively heavy serverish thing. MSIX packages can have a stream of updates expressed, but it's done by just publishing an XML file to a web server.
- MSIX doesn't try to wrap an entire Windows userland in the same way that Docker images ship entire copies of Linux userland. It's all about overlay filesystems.
It's technically a correct format, but that's not what you need to get a thriving ecosystem.
This is just the first step of the roadmap that was discussed at the conference.
Developer certificates are also coming, just like on macOS.
All security knobs enabled by default, no longer opt-in.
Again, it doesn't matter how correct it is, what features it does have or how it compares to all the other attempts from the past, what matters is that unless a developer is in the single scenario where they are forced to use it, they will probably ignore it.
Granted, before we got into the 'microsoft container concepts suck' threat, this article was specifically about win32 app isolation, so if we look at it from that perspective, this is a step up. But that's not where the mindshare or the money is.
No developer certificate, no Windows app.
Again, all, security, knobs, turned,on, by, default.
You can then either switch to macOS or ChromeOS with similar models already, use one of the mobile OSes, which have used such restrictions for years, or maybe it is finally when the exodus to Linux Desktop takes place.
Windows workloads are getting smaller, not bigger.
This attempt at a yet another microsft iteration of things like flatpak/docker/dpkg/rpm/nix etc is no more likely to be embraced than the previous ones. There is a reason default packaging of popular software is still SFX packages spewing files all over the place and not MSI or MSIX. The former is usually only included als an alternative (i.e. Chrome's "Enterprise" version) because tools like SCCM are not very useful without it.
This has to do with Microsoft trying to re-invent the wheel time after time, and consistently failing (within their own ecosystem) because they build things that contradict the desired user experience which prevents adoption. And with adoption, I mean the same kind of adoption that Docker (now OCI) has.
That is not a direct link between desktop-app sandboxing vs. microservice containers, but a comparison between doing things good enough for mass usage (Docker) vs. trying to do it 'the enterprise way' (every attempt beyond win32 so far, including COM, MSI and APPX). And it's not about their technology having bugs either (every tech does, not just MS-tech), plenty of the technical aspects are fine, but that alone is not going to drive adoption as the last few decades have shown.