zlacker

This feature depends on MSIX. My company makes Conveyor which amongst other things generates/signs MSIX files without using Microsoft's toolchain so you can ship apps from your developer laptop or Linux CI. As almost all modern/maintained Win32 apps are actually built on cross platform frameworks, being able to cross-build packages using a tool that understands Electron/JVM/Flutter build system config is quite convenient. By this point my guess is that we have more experience with MSIX in the wild than many of Microsoft's own teams do.

Surfacing this new sandbox feature looks very easy from the instructions, but before it's worth doing I'd want to talk to the product teams involved and get answers to some questions:

1. What's the purpose of this? Is it to let users install potentially malicious apps in the same way you can browse to untrusted web pages? Or is it like how Apple pitches their app sandbox on macOS, purely an opt-in security feature to reduce the blast radius of exploits? The big difference is whether permissions are surfaced in the UI.

2. If you want permissions to be visible somewhere in the UI, then presumably that would be in App Installer. Conveyor replaces App Installer with its own installer that drives MSIX via the API because App Installer is too buggy to rely on. What's the plan for fixing that?

3. Relatedly, Conveyor contains a large number of workarounds for bugs in the Windows app container and package management system, especially older versions. This has ended up being a significant part of the value the product provides, even! It seems faintly ridiculous, but the Windows package manager does actually provide a lot of useful features like silent background updates (Chrome style) and it's core to Microsoft's platform strategy. But unless Microsoft's plan is to tell everyone to buy my product (yes please) they will need to fix the bugs. Are you going to do that? Otherwise devs will bounce right off it just as they have with every other feature Microsoft adds to Windows that relies on package identity.

4. Not only fix the bugs but also, will you backport the fixes to Windows 10? I can't stress this enough. Shipping MSIX packages outside the MS store without using Conveyor is just flat out impossible if you're targeting Windows 10, because you'll quickly hit bugs that Microsoft know about but never backported the fixes for.

Microsoft people - if you want to talk, feel free to email. Address is in the profile. We can tell you what issues people hit in the wild when they ship apps this way, and maybe work together on making this a success.

>>mike_h+(OP)
> Conveyor replaces App Installer with its own installer that drives MSIX via the API because App Installer is too buggy to rely on. What's the plan for fixing that?

Have you considered making this installer open-source, and then asking Microsoft to co-develop it and ship releases of it as a replacement for App Installer?

>>derefr+13
If Microsoft wants to offer to buy the company they can email me about it, otherwise, no. It's a small firm without venture funding so we can't just open source our product.

>>mike_h+m3
I mean, from what you said, "the installer" isn't your product, no? The build system is your product. The custom installer that the build tool emits is just something you had to create as a workaround because the Microsoft one sucks, and which is a pure cost center for you, and one redundant to Microsoft's own efforts.

Wouldn't you prefer to have your build system just emitting .msix for Windows, with the expectation that all Windows systems will then run your good installer in response to opening any .msix?

>>mike_h+(OP)
This is the continuation of bringing UWP security model into Win32, and make Windows security features all enabled by default.

See BlueHat IL talk on the matter,

https://youtu.be/8T6ClX-y2AE

There are no plans for Windows 10, beyond security fixes until 2025, it is done.

EDIT: There is a BUILD 2023 talk on the matter as well.

https://youtu.be/w6VwHGPz12w

>>derefr+u4
The product is "desktop app distribution as easy as for a web app" and encompasses whatever's required to do that. It's not just the custom installer, there are workarounds for Windows bugs in a variety of different places in the product and in some modes the installer is integrated with the package contents, so it requires the two to be co-built.

>>mike_h+(OP)
These are really good questions. I've never used Conveyor, but hoo boy I've run into a lot of the same problems with MSIX.

App Installer has a nice UX on the happy path, but then you quickly discover that it will just fail for a non-negligible percent of customers.

IMO it's not a coincidence that very few first-party teams distribute their software using MSIX outside the Store. MSIX outside the store is broken, and for whatever reason the team responsible for it doesn't seem to be addressing that.

>>ripley+s31
We've got it pretty stable now, but it's taken a lot of effort. There are a few cases where Win32 changes its behavior if you're packaged, but that's unfortunately the case on every OS. Some Apple APIs work differently if you're in bundle context too, also depending on whether the app is signed.

>>mike_h+(OP)
> because you'll quickly hit bugs that Microsoft know about but never backported the fixes for.

Or you'll hit basic features which are missing. Like deploying services from your MSIX: win10 - no problem, server 2019 - are you mad? you want to deploy services on a server? of course they're not supported...