Win32 App Isolation(github.com)
github.com
Win32 App Isolation
https://github.com/microsoft/win32-app-isolation
11 comments
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
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
> 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...
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...
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.
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.
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.
> 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?
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?
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.
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?
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?
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.
Windows 8 and UWP weren't ever popular, but Microsoft is having a little more success parcelling up UWP:
* .appx became .msix; the latter also works for Win32 apps
* UWP XAML/GUI evolved into WinUI, v3 of which doesn't target UWP
* Win32 app isolation—this news—grew out of AppContainers, which were used by UWP apps
That said, what's new here? You could package (.msix) Win32 apps with partial trust, IIRC. Does this remove the need for packaging?
* .appx became .msix; the latter also works for Win32 apps
* UWP XAML/GUI evolved into WinUI, v3 of which doesn't target UWP
* Win32 app isolation—this news—grew out of AppContainers, which were used by UWP apps
That said, what's new here? You could package (.msix) Win32 apps with partial trust, IIRC. Does this remove the need for packaging?
You are correct that Win32 apps were already supported in AppContainer. What's new here is that a handful of Win32 APIs are now slowly getting plumbed into the capability system. This means Win32 apps that currently ship packaged as needing "full trust" can, if supported, reduce the requested capabilities to those that are supported by Win32 App Isolation (e.g., "system tray access").
The new stuff are basically new package (msix) capabilities that trigger new codepaths in classical Win32 APIs. Microsoft's previous app sandbox required the use of WinRT APIs that not many people have adopted.
AppContainers have supported win32 from the start, not just WinRT.
See:
https://learn.microsoft.com/en-us/windows/win32/secauthz/app...
https://learn.microsoft.com/en-us/windows/win32/api/userenv/...
https://scorpiosoftware.net/2019/01/15/fun-with-appcontainer...
See:
https://learn.microsoft.com/en-us/windows/win32/secauthz/app...
https://learn.microsoft.com/en-us/windows/win32/api/userenv/...
https://scorpiosoftware.net/2019/01/15/fun-with-appcontainer...
There are different kinds of app containers. The low level container tech doesn't care what high level APIs you use, it just blocks or redirects stuff, but if you want things like file brokering, implicit grants based on powerboxes and stuff like that then it wasn't previously available. That's what this project is adding to Windows.
edit: To clarify, all MSIX packaged apps run in an app container called Helium, but it's a very soft one that isn't meant to sandbox anything. It just redirects file IO to a special directory so installs/uninstalls are clean. You can make app containers stricter. The Chrome sandbox does that, UWP sandboxed apps do that, and now they're adding support for more strictly sandboxing ordinary Win32 apps which would otherwise break when they tried to open a file in the user's home directory.
edit: To clarify, all MSIX packaged apps run in an app container called Helium, but it's a very soft one that isn't meant to sandbox anything. It just redirects file IO to a special directory so installs/uninstalls are clean. You can make app containers stricter. The Chrome sandbox does that, UWP sandboxed apps do that, and now they're adding support for more strictly sandboxing ordinary Win32 apps which would otherwise break when they tried to open a file in the user's home directory.
I wouldn't call WinUI 3 a success.
What is new here, is that this is the continuation to make all Win32 apps sandboxed.
What is new here, is that this is the continuation to make all Win32 apps sandboxed.
> I wouldn't call WinUI 3 a success.
Fair, I would say it's somewhat actively developed, for now... Which is maybe a step above UWP XAML.
Microsoft promised to open source WinUI 3 years ago, but it keeps getting pushed back in favour of other priorities. This isn't good for a healthy community, who can only report bugs, and never fix them.
Fair, I would say it's somewhat actively developed, for now... Which is maybe a step above UWP XAML.
Microsoft promised to open source WinUI 3 years ago, but it keeps getting pushed back in favour of other priorities. This isn't good for a healthy community, who can only report bugs, and never fix them.
Wow I've been waiting for this for so long. This is literally my #1 most requested windows feature.
Imagine one day having a proper permissions system on windows and NOT having to worry whether that fancy calculator you downloaded is going to compromise your computer or whether a rce bug in CS:GO is going to steal your credit card information from the browser.
I've been looking around the repo, but I see no mention of whether and how this works with programs that need GPU access.
Imagine one day having a proper permissions system on windows and NOT having to worry whether that fancy calculator you downloaded is going to compromise your computer or whether a rce bug in CS:GO is going to steal your credit card information from the browser.
I've been looking around the repo, but I see no mention of whether and how this works with programs that need GPU access.
So I have this mod manager for Elder Scrolls: Oblivion that sets up a virtual filesystem as an overlay over the game's original directory structure, and then launches the game in a way that makes the game see the overlay as if they were the original files. I am very impressed at what seems like outright computer voodoo, I had no idea Windows had those kinds of APIs or that kind of capability.
I don't know how this tech works but I feel like we could have had this already using the tech I described above.
I don't know how this tech works but I feel like we could have had this already using the tech I described above.
Filesystem (and registry) redirection has been around in Windows for a while, and is used to e.g. make sure that pre-Vista apps still run if they do things like trying to write to "Program Files". But that all assumes that the app is not adversarial - proper sandboxing is a different story.
I'm pretty sure such thing is implemented by hooking OS functions that are dealing with directory enumeration, create/open file, etc - and then redirecting to custom code that provides virtual files & their contents. There's no standard Windows API for that, aside writing custom driver. But hooking such functions is relatively straight forward process because they are imported from well known shared libraries - you just need to make sure you hook all the functions that are relevant to filesystem operations.
This is objectively great news.
As long as it's function is to keep the program locked in, and not the user locked out from modifying it...
As long as it's function is to keep the program locked in, and not the user locked out from modifying it...
Indeed, but sadly, features designed to "keep the program locked in" can also often be miss-used to "keep thee user locked out". Only time will tell where this one goes.
And all the file sandboxing approaches I've seen so far only seem to cater for the simple "choose a single file (or directory)" workflow and break multi-file formats, any customised UX around file I/O and any other advanced workflows.
To some extent that's just laziness, because who cares for the long tail of workflows, right, and to some extent unfortunately it's a fundamental trade-off of sandboxing (the OS can't know the details of each and every file format and which files are related and need to be opened together even if the user only launched one file, the application developer does know, but is the untrusted party; being able to paste a file path directly into a GUI respectively directly edit it there can be comfortable, but it bypasses the official secure OS file picker, so again a no-go, etc. etc.).
To some extent that's just laziness, because who cares for the long tail of workflows, right, and to some extent unfortunately it's a fundamental trade-off of sandboxing (the OS can't know the details of each and every file format and which files are related and need to be opened together even if the user only launched one file, the application developer does know, but is the untrusted party; being able to paste a file path directly into a GUI respectively directly edit it there can be comfortable, but it bypasses the official secure OS file picker, so again a no-go, etc. etc.).
The Mac sandbox grants access to the whole directory when a file is selected, iirc. I'm curious what you mean by customized UX around file I/O?
> The Mac sandbox grants access to the whole directory when a file is selected, iirc.
Does it, by default? https://developer.apple.com/documentation/security/app_sandb... [1] doesn't look like it, and there seem to be special features for requesting access to related files which wouldn't be necessary if selecting a file gave you access to the whole directory. Though I've got no Mac, so no idea how this actually works in practice – maybe you're right, though it'd also noticeably weaken the sandbox, which seems strange.
> I'm curious what you mean by customized UX around file I/O?
Simply things like a directory tree control integrated into the UI, IrfanView's directory switcher (when you reach the start or end of a directory while browsing through your pictures, it pops up a dialogue that allows you to easily – and without having to use the mouse – navigate up and down the directory tree to a different folder), or even something as simple text input control that allows direct editing instead of always having to go via an official OS file picker.
[1] It seems like Apple does have some support for storing relative file references after all ("document-scoped bookmarks"), so that picking something like a master project file also gives access to all related documents, no matter how complex the file format is, though I have no idea whether those really work even when moving files between different devices, and they almost certainly won't work for cross-platform file formats, because non-Mac software will of course have no idea about that kind of thing. And last time I looked, Android's and Windows's sandbox implementation didn't have anything comparable, and Linux likely doesn't, either…
Does it, by default? https://developer.apple.com/documentation/security/app_sandb... [1] doesn't look like it, and there seem to be special features for requesting access to related files which wouldn't be necessary if selecting a file gave you access to the whole directory. Though I've got no Mac, so no idea how this actually works in practice – maybe you're right, though it'd also noticeably weaken the sandbox, which seems strange.
> I'm curious what you mean by customized UX around file I/O?
Simply things like a directory tree control integrated into the UI, IrfanView's directory switcher (when you reach the start or end of a directory while browsing through your pictures, it pops up a dialogue that allows you to easily – and without having to use the mouse – navigate up and down the directory tree to a different folder), or even something as simple text input control that allows direct editing instead of always having to go via an official OS file picker.
[1] It seems like Apple does have some support for storing relative file references after all ("document-scoped bookmarks"), so that picking something like a master project file also gives access to all related documents, no matter how complex the file format is, though I have no idea whether those really work even when moving files between different devices, and they almost certainly won't work for cross-platform file formats, because non-Mac software will of course have no idea about that kind of thing. And last time I looked, Android's and Windows's sandbox implementation didn't have anything comparable, and Linux likely doesn't, either…
Hmmm. I'd have to check. The use case given for that API (good spot) is for IDEs, where files are often in different sub-directories, so granting folder access wouldn't be enough. But you might be right, it's been a while since I looked at the details of this stuff. I do remember the bookmarks mechanism. It's all quite well thought out relative to other platforms (as per usual for Apple), but for as long as Apple treat it as an exploit mitigation mechanism rather than as a way to rapidly run untrusted code it's not going to get much traction outside the App Store where they force it.
My guess is that their security folks aren't convinced by the robustness of the sandbox and don't want the pain of trying to defend it, which is a pity (for them), because it just throttles their own platform and pushes people towards the web. The browser guys apparently can define a sandboxable platform: why can't Apple?
Re: custom file browsers. Yes, that's a good point. I think you can request access to whole parts of the file tree though even when sandboxed. You have to mark them as exceptions via entitlements and it's automatically granted. Because Apple see the sandbox as a way to mitigate exploits and not allow execution of untrusted code, that sort of approach works fine.
My guess is that their security folks aren't convinced by the robustness of the sandbox and don't want the pain of trying to defend it, which is a pity (for them), because it just throttles their own platform and pushes people towards the web. The browser guys apparently can define a sandboxable platform: why can't Apple?
Re: custom file browsers. Yes, that's a good point. I think you can request access to whole parts of the file tree though even when sandboxed. You have to mark them as exceptions via entitlements and it's automatically granted. Because Apple see the sandbox as a way to mitigate exploits and not allow execution of untrusted code, that sort of approach works fine.
What exactly does it do for me as a user?
It’s a security boundary. It lets you control the resources an application has access to. For example, if that cool weather app you just installed asks for access to your Documents directory, or your camera or microphone, you can say no.
I see, it lets me install random .EXEs from sketchy web sites on my Windows machine without having to worry. Sounds safe.
Whats your point? You just ran a bunch of untrusted code when you visitied this website.
Running a native binary in an environment with a large attack space and user level permissions is not NEARLY the same as running javascript in a browser with all of its sandboxing, isolation, and controls. And you know it.
Untrusted code running in a well-defined and maintained sandbox.
Still stuff manages to escape constantly
You can find exploits on gh for older chromium versions easily
You can find exploits on gh for older chromium versions easily
Even so it's disingenuous to compare running native code in an OS w/o a capabilities model to running Javascript in a browser.
Yes and....
Visiting a website and running Javascript vs. running a native application aren't equivalent. Browser sandbox exploits are "a thing" but that doesn't make the situations the same.
Yes and WASM can be sandboxed just as easily as JavaScript.
There is nothing "magical" about web browsers in that regard.
There is nothing "magical" about web browsers in that regard.
I don’t follow where you’re going.
I didn’t say there was anything “magical” about browsers. They have a sandbox for JavaScript, by default. Windows doesn’t have a sandbox for native apps, by default.
A parent poster seemed to be making a statement of equivalency between running a native application in Windows and running JavaScript in a browser. I don’t think they’re equivalent.
That’s what I’m saying.
I didn’t say there was anything “magical” about browsers. They have a sandbox for JavaScript, by default. Windows doesn’t have a sandbox for native apps, by default.
A parent poster seemed to be making a statement of equivalency between running a native application in Windows and running JavaScript in a browser. I don’t think they’re equivalent.
That’s what I’m saying.
We are literally talking about an environment for running Win32 apps in a sandbox
Yay, it's the latest attempt at Project Centennial!
(For context, Microsoft has been trying for 7 years various methods to get developers to please package their apps in some way. Almost nobody has ever bit - to the point the Microsoft Store only has been having some recent success by promising packaging isn't required.)
https://petri.com/microsofts-project-centennial-unsuccessful...
(For context, Microsoft has been trying for 7 years various methods to get developers to please package their apps in some way. Almost nobody has ever bit - to the point the Microsoft Store only has been having some recent success by promising packaging isn't required.)
https://petri.com/microsofts-project-centennial-unsuccessful...
I have spent weeks of my life trying to get windows packaging to work. Twice with APPX, twice with MSIX. Mostly with greenfield C# apps, sometimes with existing WPF apps. Every year I think: surely it'll work now, they just published another blog post touting the new features? No. Every time I run into something that's not documented how to be done, something that's not implemented, or something that's broken, often with a detailed bug report that nobody at Microsoft has bothered responding to (e.g. [0] one of many).
Windows is in maintenance mode. Nothing new and substantial they create will ever get to a working state, they just don't have the resources. I have given up.
[0]: https://github.com/microsoft/microsoft-ui-xaml/issues/8141
Windows is in maintenance mode. Nothing new and substantial they create will ever get to a working state, they just don't have the resources. I have given up.
[0]: https://github.com/microsoft/microsoft-ui-xaml/issues/8141
There are quite a few packaged apps in the store. I personally made 2.
If Microsoft would make it easy and free to package apps (and without combining it with sandboxes) all developers would do it.
It's a black art (e.g. Windows Installer). But these days using open tools it's not so bad. A desktop app can be built early with only free microsoft tools and really well packaged with free non-microsoft (ok microsoft-adjacent) tools like Squirrel. That wouldn't make them isolated in the sense of store apps, however.
I actually like WiX[1] — it has a bit of a learning curve, but, so long as I'm building on Windows and don't stray far from the default UI flows, I haven't found an easier tool for creating Windows installers as part of a product build process, especially those that require Windows-specific bits like COM component registration, Windows service management, setting restrictive ACLs on installed components, etc.
And while I'm not aware of any way to sandbox Windows Installer itself, I'm curious if AppContainer isolation can be applied to applications and services installed via MSI, which would still be quite useful even if the installation process itself is unrestricted.
Alternatively, now that MSIX supports service installation[2], I wonder whether an MSIX including a Windows service and a collection of client applications can be configured so everything runs within one AppContainer, isolated from the rest of the system, and whether permission to access specific external directories chosen by users in a configuration GUI can be transparently (to the user) delegated to the related service.
Alas, none of this is useful to me unless it's compatible with at least the most recent version of Windows 10: very few of my customers are running Windows 11, and I suspect many won't upgrade until Windows 10 is no longer supported (optimistically; as of last year, I was still getting occasional support requests from customers running older versions of our software on Windows Server 2003 R2).
[1] https://wixtoolset.org
[2] https://learn.microsoft.com/en-us/windows/msix/supported-pla...
And while I'm not aware of any way to sandbox Windows Installer itself, I'm curious if AppContainer isolation can be applied to applications and services installed via MSI, which would still be quite useful even if the installation process itself is unrestricted.
Alternatively, now that MSIX supports service installation[2], I wonder whether an MSIX including a Windows service and a collection of client applications can be configured so everything runs within one AppContainer, isolated from the rest of the system, and whether permission to access specific external directories chosen by users in a configuration GUI can be transparently (to the user) delegated to the related service.
Alas, none of this is useful to me unless it's compatible with at least the most recent version of Windows 10: very few of my customers are running Windows 11, and I suspect many won't upgrade until Windows 10 is no longer supported (optimistically; as of last year, I was still getting occasional support requests from customers running older versions of our software on Windows Server 2003 R2).
[1] https://wixtoolset.org
[2] https://learn.microsoft.com/en-us/windows/msix/supported-pla...
I really doubt that at this point. Developers have learned that everything Microsoft says to do for Windows, since 2012, will be garbage within a few years. Guaranteed.
Learned Silverlight for Windows Phone development? Too bad, it's UWP now. And the XAML is incompatible.
Learned WinRT for Windows 8/8.1 app development? Too bad, it's UWP now. And the XAML is incompatible.
Packaged your App for APPX? Too bad, it's MSIX now.
You learned how to develop UWP apps? Too bad, the User Interface layer has been ripped out of UWP, it's now called WinUI 3, and it doesn't even run on UWP. Better port your UWP app back to Win32 now, I guess. Why did you even learn UWP again?
You went and learned WinUI 3 like we recommended? Well, unlike WinUI 2, it doesn't have a visual designer, and it doesn't have input validation, or a bunch of other WinUI 2 features. So, depending on what your app needs, you might have a mix of UWP and Win32, because WinUI 2 is UWP-exclusive and WinUI 3 is Win32-exclusive and neither has all the features of the other. Progress!
You built your Windows 8 app with WinJS? Well, sucks to be you, rewrite it in entirety, WinJS was scrapped.
You ported your app from iOS with Project Islandwood? Well, again, that sucks. It was brilliant, it made pulling apps over from iOS much easier, but it's dead. Rewrite!
You decided to hang it all, develop for good old WPF, but wanted to use the Ink Controls from UWP? Great, we developed a scheme for that called XAML Islands which made so you could have some of the best UWP controls in your old app. Then we released WinUI 3, completely broke it, and made it so complicated nobody can figure it out. So broken; even the Windows Team doesn't use it and is writing the modern Windows components for File Explorer with the old version.
But of course, that would require WinUI 2, for UWP, inside Win32 which is the main feature of the broken WinUI 3; which means that the Windows Team has a bastardized version of XAML Islands for their own use that nobody else has (literally), to modernize the taskbar and File Explorer and built-in apps like Paint, that nobody who wants to emulate them can borrow. Their apps don't look modern and their users complain? Suckers, go learn WinUI 3, even though our own teams couldn't figure it out.
You wanted your app on the Microsoft Store? Well, good news, package it together with this obtuse script that requires 30 command-line arguments, perfect file path formats, and a Windows 10 Pro License! Oh, you didn't do that? Do it 5 years later with MSIX and a GUI this time! Oh, you didn't do that? Forget the packaging, just submit a URL to your file download location. Anyone who bothered with the packaging wasted hours for no real purpose.
Did I mention Xamarin? A XAML dialect of its own, that supports all platforms. But it runs on Mono instead of the authentic .NET, so you'd better... work around the quirks. Also it's called MAUI now, and runs on .NET now. But that might break a few things so hang around for over a year's worth of delays. We'll get it running for sure!
Oh, and don't forget about ARM! The first attempt to get everyone to support ARM was in 2012 with a Windows version called... No, no, no. Go past this. Pass this part. In fact, never play this again. (If you want to imagine pain, imagine running Windows and Microsoft Office on a ARM CPU that came three generations before the Tegra X1 in the Nintendo Switch. Surface RT ended with a $900M write-off.)
And so on...
Or, you could just ignore everything, create a Windows Forms (22 years strong) or WPF app (17 years strong), and continue business like usual. Add in DevExpress or Telerik controls and you are developing at the speed of light. And if you need a fancier UI, use Avalonia, Electron, React, or Flutter.
Learned Silverlight for Windows Phone development? Too bad, it's UWP now. And the XAML is incompatible.
Learned WinRT for Windows 8/8.1 app development? Too bad, it's UWP now. And the XAML is incompatible.
Packaged your App for APPX? Too bad, it's MSIX now.
You learned how to develop UWP apps? Too bad, the User Interface layer has been ripped out of UWP, it's now called WinUI 3, and it doesn't even run on UWP. Better port your UWP app back to Win32 now, I guess. Why did you even learn UWP again?
You went and learned WinUI 3 like we recommended? Well, unlike WinUI 2, it doesn't have a visual designer, and it doesn't have input validation, or a bunch of other WinUI 2 features. So, depending on what your app needs, you might have a mix of UWP and Win32, because WinUI 2 is UWP-exclusive and WinUI 3 is Win32-exclusive and neither has all the features of the other. Progress!
You built your Windows 8 app with WinJS? Well, sucks to be you, rewrite it in entirety, WinJS was scrapped.
You ported your app from iOS with Project Islandwood? Well, again, that sucks. It was brilliant, it made pulling apps over from iOS much easier, but it's dead. Rewrite!
You decided to hang it all, develop for good old WPF, but wanted to use the Ink Controls from UWP? Great, we developed a scheme for that called XAML Islands which made so you could have some of the best UWP controls in your old app. Then we released WinUI 3, completely broke it, and made it so complicated nobody can figure it out. So broken; even the Windows Team doesn't use it and is writing the modern Windows components for File Explorer with the old version.
But of course, that would require WinUI 2, for UWP, inside Win32 which is the main feature of the broken WinUI 3; which means that the Windows Team has a bastardized version of XAML Islands for their own use that nobody else has (literally), to modernize the taskbar and File Explorer and built-in apps like Paint, that nobody who wants to emulate them can borrow. Their apps don't look modern and their users complain? Suckers, go learn WinUI 3, even though our own teams couldn't figure it out.
You wanted your app on the Microsoft Store? Well, good news, package it together with this obtuse script that requires 30 command-line arguments, perfect file path formats, and a Windows 10 Pro License! Oh, you didn't do that? Do it 5 years later with MSIX and a GUI this time! Oh, you didn't do that? Forget the packaging, just submit a URL to your file download location. Anyone who bothered with the packaging wasted hours for no real purpose.
Did I mention Xamarin? A XAML dialect of its own, that supports all platforms. But it runs on Mono instead of the authentic .NET, so you'd better... work around the quirks. Also it's called MAUI now, and runs on .NET now. But that might break a few things so hang around for over a year's worth of delays. We'll get it running for sure!
Oh, and don't forget about ARM! The first attempt to get everyone to support ARM was in 2012 with a Windows version called... No, no, no. Go past this. Pass this part. In fact, never play this again. (If you want to imagine pain, imagine running Windows and Microsoft Office on a ARM CPU that came three generations before the Tegra X1 in the Nintendo Switch. Surface RT ended with a $900M write-off.)
And so on...
Or, you could just ignore everything, create a Windows Forms (22 years strong) or WPF app (17 years strong), and continue business like usual. Add in DevExpress or Telerik controls and you are developing at the speed of light. And if you need a fancier UI, use Avalonia, Electron, React, or Flutter.
Everytime I ponder getting into Windows desktop development I see a portion of this picture, think about doing all this in Java instead, then remember that that is its own UI mess (although overall less storied but worse functionality wise), then think Electron would be better, try to get Typescript and Vue.js to play nice in Electron, run for the hills, briefly consider if building a desktop UI in Unreal or Unity would be the easiest, then just go back to playing video games.
Edit: Thank you for giving such a nice summary of the current landscape of UI dev in Windows native development.
Edit: Thank you for giving such a nice summary of the current landscape of UI dev in Windows native development.
Thankfully WinForms and WPF are still around and supported in current dev tooling.
You know how Electron allows you to spawn a native backend server as a subprocess, to generate the pages that the Electron frontend interacts with? And how this means that you can write 90% of your program in some native language, and just do a thin UI in JS?
I wonder why nobody's created a "XAML projector" to allow you to create Windows UI applications the same way — by writing some platform-neutral app in Java or whatever, that needs no native libs loaded into it, but rather just knows how to generate XAML and, when told it's running on Windows, expects to be connected to over a socket by an also-XAML-speaking client.
Or I could say the same about Qt's QML.
(In fact, at this point I have to wonder: if modern UI frameworks almost always use an intermediary "view definition language" to communicate with the application anyway, then why are they even designed to load as native libraries resident inside the process? Why not just reinvent the X protocol on a higher level — have the UI toolkit be a local (socket-activated) daemon, and then all the things that use it are just clients that speak its protocol? I know, you can't directly draw to the screen from your backend this way. X11 DRI worked, though, and IMHO was a very good idea — SHM buffers are way easier to get working in most language runtimes than an FFI binding of some C++ UI toolkit is. Or maybe we can do one better, these days: just expose WebGL commands addressable to WebGL canvas objects over the toolkit's protocol.)
I wonder why nobody's created a "XAML projector" to allow you to create Windows UI applications the same way — by writing some platform-neutral app in Java or whatever, that needs no native libs loaded into it, but rather just knows how to generate XAML and, when told it's running on Windows, expects to be connected to over a socket by an also-XAML-speaking client.
Or I could say the same about Qt's QML.
(In fact, at this point I have to wonder: if modern UI frameworks almost always use an intermediary "view definition language" to communicate with the application anyway, then why are they even designed to load as native libraries resident inside the process? Why not just reinvent the X protocol on a higher level — have the UI toolkit be a local (socket-activated) daemon, and then all the things that use it are just clients that speak its protocol? I know, you can't directly draw to the screen from your backend this way. X11 DRI worked, though, and IMHO was a very good idea — SHM buffers are way easier to get working in most language runtimes than an FFI binding of some C++ UI toolkit is. Or maybe we can do one better, these days: just expose WebGL commands addressable to WebGL canvas objects over the toolkit's protocol.)
If you want to do windows desktop development, just find the oldest technique that still works and use that. I think you can probably still find pre-.net visual studio out there and use it, and it'll work. You'll miss out on some stuff, but oh well? If you get to the point where you have thousands of people hounding you about high dpi support, you've made it.
Most developers completely ignored everything Microsoft had to offer since Windows 7 and because Microsoft is Microsoft all their technologies continue to work and keep getting updated.
I, for one, never stopped developing in WPF.
I, for one, never stopped developing in WPF.
JVM UI isn't so bad. I've written some pretty modern looking UI with it. The sophisticated controls are all there.
Modern JavaFX theme: https://github.com/mkpaz/atlantafx
Modern Swing theme: https://github.com/JFormDesigner/FlatLaf
And these days Compose Multiplatform: https://www.jetbrains.com/lp/compose-multiplatform/
I tend to use Kotlin rather than Java but of course Java is perfectly fine too. You can also use Clojure.
If you use any of those frameworks you can distribute to Win/Mac/Linux in one command with Conveyor. It's free for open source apps and can do self-signing for Windows if you don't want to pay for the certificates or the Store (but the Store is super cheap these days, $19 one off payment for an individual). Also supports Electron and Flutter if you want to use those.
From those frameworks you can then access whatever parts of the Windows API you want. Flutter even has WinRT bindings these days! So it's not quite so bad.
Modern JavaFX theme: https://github.com/mkpaz/atlantafx
Modern Swing theme: https://github.com/JFormDesigner/FlatLaf
And these days Compose Multiplatform: https://www.jetbrains.com/lp/compose-multiplatform/
I tend to use Kotlin rather than Java but of course Java is perfectly fine too. You can also use Clojure.
If you use any of those frameworks you can distribute to Win/Mac/Linux in one command with Conveyor. It's free for open source apps and can do self-signing for Windows if you don't want to pay for the certificates or the Store (but the Store is super cheap these days, $19 one off payment for an individual). Also supports Electron and Flutter if you want to use those.
From those frameworks you can then access whatever parts of the Windows API you want. Flutter even has WinRT bindings these days! So it's not quite so bad.
This really comes down to Microsoft's desire to kill off Win32 and developers' and users' desire to keep using Win32 coming to a head.
As it turns out, Windows is nothing without Win32 which developers and users want. Consequently, Win32 has subdued every single attempt from Microsoft to replace it. Every. Single. Attempt.
The recent moves back to Win32 are essentially Microsoft finally throwing in the towel, though the jury is still out if they understand why Win32 keeps on slaying them at every turn.
As it turns out, Windows is nothing without Win32 which developers and users want. Consequently, Win32 has subdued every single attempt from Microsoft to replace it. Every. Single. Attempt.
The recent moves back to Win32 are essentially Microsoft finally throwing in the towel, though the jury is still out if they understand why Win32 keeps on slaying them at every turn.
And people wonder why devs will reach for Electron... same tooling as web-apps, rich UI/UX with support for scaling and accessibility, and bonus, you can also target mac and even linux with a relatively low level of extra effort.
Avalonia, React (Native) and Flutter all seem to be doing pretty well as alternatives as well. All with cross platform support and less friction than the Microsoft solution(s) for this. That MS didn't support MAUI with at least Linux+GTK/Gnome from the start, who knows, it was a massive miss for a lot of devs imo.
Avalonia, React (Native) and Flutter all seem to be doing pretty well as alternatives as well. All with cross platform support and less friction than the Microsoft solution(s) for this. That MS didn't support MAUI with at least Linux+GTK/Gnome from the start, who knows, it was a massive miss for a lot of devs imo.
Thank you for summarizing why I left Windows app development and haven't looked back
[deleted]
This sums it up perfectly. It's fatiguing.
It's also (at least partially) intentional. Microsoft keeps you so busy on the treadmill you don't stop to ask "wait, should we be doing this?"
Microsoft's goals and 3rd party developer goals stopped being aligned and it's taken just about this long for them to realize that it isn't going to work.
And to top it all off, even WPF has quirks. I can tell which apps on my Windows gaming tower are built with it because for some reason the framerate on my cursor drops to 60FPS or below on my 240hz monitor when it's within the bounds of a WPF window.
That's the power of the horribly unoptimized DX9-based renderer WPF was (is still?) built on.
Worst part of WPF for me was the tooling that crashed whenever you so much as looked at it wrong.
Worst part of WPF for me was the tooling that crashed whenever you so much as looked at it wrong.
I can’t speak for professional development, but for hobby projects I personally had a lot of fun with WinAPI and GDI. SDL is good too. The churn of everything you mentioned was too much for me and it’s comforting playing with something that isn’t going anywhere for better or worse.
You missed .NET Native and screwing devs replacing C++/CX with C++/WinRT, the return to ATL roots, editing IDL files without VS tooling and manually merging generated C++ code.
But hey, from all the warts, and screw-ups, the other gardens aren't much better.
But hey, from all the warts, and screw-ups, the other gardens aren't much better.
Exactly my experience with Microsoft development. Since 2011 I’ve gone from working at Microsoft on Windows Phone full time to mostly leaving the tech industry and running a theater, largely because I bet on the Microsoft horse and it turns out that was a losing bet for exactly these reasons. I stopped trying to keep up, because what’s the point? When I do still make programs using C#, they are generally command line or Windows Forms, and intended for my personal use.
Their own internal developers don't do it, so why would ISV's?
I think they are getting bit by their wishes to make it both perfect and backwards compatible at the same time.
Even a janky port of RPM or DPKG or OCI with cgroups would have been a better way to move forward. But because MS doesn't have the tools, the ecosystem or the willpower to drop legacy methods and create a proper self-hosting toolbox OS they will never get there.
"Enterprise Development" is the antithesis of successful packaging. Even Apple's half-assed PAX+Shellscripts method (.pkg) is decades ahead of whatever MS keeps pulling out of their hat.
Even a janky port of RPM or DPKG or OCI with cgroups would have been a better way to move forward. But because MS doesn't have the tools, the ecosystem or the willpower to drop legacy methods and create a proper self-hosting toolbox OS they will never get there.
"Enterprise Development" is the antithesis of successful packaging. Even Apple's half-assed PAX+Shellscripts method (.pkg) is decades ahead of whatever MS keeps pulling out of their hat.
Is this based on a similar technology that once shown on windows 10X years ago?
Windows 10X was a re-architecture of Windows, and because developers weren't repackaging their apps, 10X was trying to figure out how to automatically package apps from unpackaged installers, and run them with compatibility for old Windows without affecting the modern 10X architectural design. It was not successful.
It's odd that it failed; https://en.wikipedia.org/wiki/VMware_ThinApp was doing this literally 20 years ago and worked just fine. (I used it myself.)
IIRC, it used a filesystem driver shim that rerouted all FS writes during installation into an overlay filesystem image; and then generated a self-unpacking executable, embedding that overlay image, that unpacked the core EXE and spawned it shimmed to read from the overlay image.
What did Windows 10X do that was different than that?
IIRC, it used a filesystem driver shim that rerouted all FS writes during installation into an overlay filesystem image; and then generated a self-unpacking executable, embedding that overlay image, that unpacked the core EXE and spawned it shimmed to read from the overlay image.
What did Windows 10X do that was different than that?
> worked just fine. (I used it myself.)
a lot of things work just fine and are still failures from the management's point-of-view
a lot of things work just fine and are still failures from the management's point-of-view
They attempted to abuse/reuse a in-house technology called VAIL. There were not just some compatibility issues; but battery life and performance were just bad.
Virtualized Application Interface Layer… did anyone internally refer to this as “WINE for Windows”? ;)
From a quick web search, VAIL was supposed to only be used as a fallback for when RAIL (i.e. a cloud streaming service for your Win32 apps) wasn’t available. So I assume it didn’t necessarily have to be “good” — it was the “safe mode” of Win32 compatibility, per se. It just had to be there as a rare last resort.
But was RAIL any good? Did it even get built?
From a quick web search, VAIL was supposed to only be used as a fallback for when RAIL (i.e. a cloud streaming service for your Win32 apps) wasn’t available. So I assume it didn’t necessarily have to be “good” — it was the “safe mode” of Win32 compatibility, per se. It just had to be there as a rare last resort.
But was RAIL any good? Did it even get built?
[deleted]
Is this microsoft-docker for GUI apps?
More like yet another half-assed attempt at cgroups. Not saying cgroups is chopped liver, but at least it has in broad use with lots of users, tools and experience over a long period of time.
Microsoft has yet to come up with something even half as useful and popular. So far their best effort has been WSL2, and it's working well because it's linux, not because it's windows containers (which is something else).
This is pretty frustrating because they have plenty of money and smart people to throw at it, yet at every turn we get something that just doesn't match what people want and need, instead we get something that might look good on a keynote slide.
Microsoft has yet to come up with something even half as useful and popular. So far their best effort has been WSL2, and it's working well because it's linux, not because it's windows containers (which is something else).
This is pretty frustrating because they have plenty of money and smart people to throw at it, yet at every turn we get something that just doesn't match what people want and need, instead we get something that might look good on a keynote slide.
Windows has had cgroups before they were even an idea on Linux via Job API.
That's the problem, the Job API is not cgroups and cannot be used as cgroups.
NT also had multiple personalities or subsystems before KVM or QEMU were even thought of, yet here we are, a useless feature with no traction and no ecosystem.
The point isn't the features that a thing like cgroups provides, it's the adoption, and that is something you cannot enterprise your way into like you can with desktop software like office.
If you reverse the statement: why is the Job API not used with OCI, Windows Containers or WSL, and was a replacement created (twice no less, WSL1 and WSL2 are very different) and a virtual machine with linux the only real adopted method for containers.
(answer: because everything else that was attempted just failed one way or another, regardless of de academic or enterprise-ish correctness of those attempts)
NT also had multiple personalities or subsystems before KVM or QEMU were even thought of, yet here we are, a useless feature with no traction and no ecosystem.
The point isn't the features that a thing like cgroups provides, it's the adoption, and that is something you cannot enterprise your way into like you can with desktop software like office.
If you reverse the statement: why is the Job API not used with OCI, Windows Containers or WSL, and was a replacement created (twice no less, WSL1 and WSL2 are very different) and a virtual machine with linux the only real adopted method for containers.
(answer: because everything else that was attempted just failed one way or another, regardless of de academic or enterprise-ish correctness of those attempts)
I thought jobs were used for Windows Containers: "Windows containers utilize job objects to group and track processes associated with each container. Resource controls are implemented on the parent job object associated with the container."
https://learn.microsoft.com/en-us/virtualization/windowscont...
https://learn.microsoft.com/en-us/virtualization/windowscont...
Ah, you are right. I thought it mostly relied on Hyper-V isolation (a bit like core isolation) and the process grouping was mostly a bonus inside the Hyper-V context, but apparently this works without Hyper-V as well so it would make sense that you'd just use the Job API.
Maybe if there was some ProjFS-style text I/O for the Job API someone would have made a OCI-like container format, but I suppose even then it would be too different to be embraced like Docker was when it was released. You'd need to have it combined with WinFsp or a FUSE-alike adapter and it might even be possible to have layers and use a union/merge/overlay FS. Putting that side-by-side with containerd and cgroups2, it would still look rather Frankenstein-ish; not very windows-y, and not linux-ish either.
Maybe if there was some ProjFS-style text I/O for the Job API someone would have made a OCI-like container format, but I suppose even then it would be too different to be embraced like Docker was when it was released. You'd need to have it combined with WinFsp or a FUSE-alike adapter and it might even be possible to have layers and use a union/merge/overlay FS. Putting that side-by-side with containerd and cgroups2, it would still look rather Frankenstein-ish; not very windows-y, and not linux-ish either.
MSIX files are Microsoft's equivalent of OCI containers and do all those things. It's not well known but here's a brief rundown of the format and tech:
- 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.
- 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.
But that's the problem, isn't it? It tries to be too much of an 'enterprise solution' instead of a developer-centric ship-your-stuff method. It's not getting traction, and it's not compatible with anything.
It's technically a correct format, but that's not what you need to get a thriving ecosystem.
It's technically a correct format, but that's not what you need to get a thriving ecosystem.
It is getting traction for everyone targeting the Windows Store, and long term, as discussed at Blue Hat IL 2023, Windows will be locked down by default.
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.
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.
So in essence it's getting no traction, it's just force-fed (which doesn't require traction) and only if you are targeting the windows store. This is the same pattern as they followed with all the other attempts Microsoft made over the years, I doubt the result will be any different.
Store will also be the only way eventually.
No developer certificate, no Windows app.
Again, all, security, knobs, turned,on, by, default.
No developer certificate, no Windows app.
Again, all, security, knobs, turned,on, by, default.
It's compatible with (nearly) all Windows apps, modulo bugs and missing AppXManifest features.
So from a developer perspective (in the OCI ecosystem), it's perhaps 10% new GUI stuff, and then 10% of what Docker does, and Docker doesn't even do its own stuff all that well. Unless someone really wants that GUI stuff (as in, presenting the packaged application with a GUI, something OCI doesn't do well), this will never get picked unless forced, and if forced people will not use it because they enjoy it or because it has ecosystem traction, but because they were forced.
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.
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.
If you had spent any time reading the related Blue Hat content, this is the first step alongside developer certificates, to bring UWP model to across all Windows workloads.
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.
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.
I'm not really interested in that dead-end avenue. Bulk usage is all browser based, most basic applications that do have a desktop-based client are essentially packaged chrome browsers, and high-performance apps are so custom and so tied to old APIs that they wouldn't work with any of the new container methods Microsoft attempted over the years.
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.
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.
So what does this mean for developers writing software plugins or inter opts for other applications. Seems like more of a mess for developers to deal with.
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.