Win32 and .NET desktop apps can now be published in the Windows Store
blogs.windows.com
blogs.windows.com
I wonder why MS didn't go this way from the beginning instead of pushing that Frankensteinian half-desktop/half-mobile monstrosity called WinRT^H^H^H UWP on us.
The UWP application model has been modelled after the (now 10 years old) iOS/Android app model, created in a time when mobile devices had a lot less memory and performance than notebooks. Win32 is a pretty bad desktop API, but UWP somehow managed to be even worse because it is an outdated mobile OS ported back into the traditional desktop environment, and everything that is not 'mobile' (mouse, keyboard, window management, ...) has been implemented as an afterthought. For games (which I guess are the main usage for old-school desktop computers now), UWP is an especially bad fit.
I'm all for increasing security by running applications in a sandbox with granular permissions. However I am against 'walled gardens' curated by platform owners, this closed-platform model kills innovation. Unfortunately these two different things got thrown into the same pot by Apple, Google, and now MS. UWP somehow manages to combine the worst aspects of a dead app shop, a dead mobile platform, and walled-garden power phantasies.
All of these problems aren't fixed with the Win32 sandbox though, I'm pretty sure this is just an emulation layer on top of UWP, so all UWP limitations would still apply.
In fact, they don't really deprecate things. They may stop pushing something as the new hotness...but VB6 apps still run on windows. Those data access technologies that no one uses anymore...those still work on windows. If you are worried about your investment in time not being the new hotness, well that's one thing. If you are worried about your investment in effort being abandoned...they have done more to support backwards compatibility that I think is even reasonable.
I had an ex-girlfriend whose employer made a big bet on Silverlight for their web app platform... in 2012. Having to rewrite it all in HTML5 and JS a year later almost put them under.
I dig what you are saying though. They had some very confused messaging about the web as a platform for a long time. They finally stopped the BS, though, and have gone whole hog on the web.
I wonder how Adobe has "kept talent" without rebuilding photoshop?
If you are worried about keeping your personal skills up to date and focused on an area that will earn you personally a living then you should know that some of the most highly paid people I've met in technology code for some of the most niche platforms. I mean serious f*ck off money. Say it with me...AS400. (Or ISeries or whatever the hell it's called now.)
By grabbing their users by the sack and demanding cash they don't deserve under threat of denying access to ones entire body of work.
The limitations will show, as more and more usecases will be attempted, and surely many will be addressed.
Personally I hope once the global filesystem concept will be gone, and apps will use isolated or shared storages where shared storage will get explicit access rights for each app/user it is shared with.
The old system had defaults originating from the single user non-multimedia usecases left over as a legacy, but currently we have so many things going on our computers, that privacy/security needs a rethinking of old concepts to cope with new challenges.
I very much hope not, since default and easy global sharing is what makes desktop OSs so very useful, and a lot of this sharing is spontaneous, creative, and ad-hoc. Besides, we already have things like filesystem permissions. By all means have a sandbox for "the untrusteds", but I don't want the equivalent of being forced into the "everything which is not explicitly allowed is forbidden" bureaucracy.
I see your point, that the current solution offers a simple (and vulnurable solution). This is why I have said that these challenges need to be addressed. The current solutions may not be the best, but for an evolution to start we need to make changes, and try different approaches.
I thought that's how Android's filesystem permission works? Each app runs as its own "user", and the FS permission bits restrict what it can access. This is a common solution in the Unix world. The problem on Android is that the filesystem is relatively hidden, and there's no easy way to change those permissions to allow more or less access.
Perhaps having the user as "root", along with all the actually-trusted apps (including those from the OS), and everything else setuid to their own per-app users, would be a useful configuration. Everything that's fully trusted is free to interact, while isolating those which aren't.
I do not like the fact, that an installation of for example a game needs admin rights, and has every chance to access data it should not be able to do.
That's possibly because of a need to install kernel-mode components (might be DRM related). If you're truly paranoid, VMs would be a better choice for isolation. But fundamentally, I don't believe in installing/using/changing apps that I don't completely trust, so perhaps this is a less of a problem for me and I'd rather have everything be "open".
They can if you adopt a user per app model. I thought this is what android/UWP did under the hood.
> I do not like the fact, that an installation of for example a game needs admin rights, and has every chance to access data it should not be able to do.
I doesn't. The biggest cause of this is the default of requiring admin to access program files, even if it's only touching it's own new folder.
Installing off steam happens without admin rights, apart from the VC++ redistributable (why is that a thing?).
It comes with some great benefits though, like easy modding. Imagine if my text editor couldn't access my games folder?
Not that I want to give malware devs any ideas, but I would be surprised if the above never crosses their minds. I suspect the main reason that it hasn't happened to date is that most malware devs are likely gamers and don't want to defecate where they eat.
As for the "great benefits", as much as I like modding, I like my system security a little bit better. There are definitely ways to do modding both securely and easily (and reproducibly) using things kind of like Docker containers and patch overlays, and I'd love it if, say, Valve invested some time into that as a secure platform service. For some of the games it supports Steam Workshop gets sort of, partly there, some of the time...
(But ultimately, I think game developers mostly don't care about security and Steam especially isn't very well incentivized to move out of the dark ages anytime soon. Bringing things back around, I'm hopeful that with the UWP platform exploring things like modding as a service we'll at least see that sort of innovation from Microsoft and the UWP converge towards the best of all worlds, eventually, hopefully...)
[1] Steam has a baroque assortment of DRM and anti-cheat mechanisms, obviously, but only while it is running and even then most of them are passive when a game isn't running. Steam absolutely has no idea what would be legitimate modding to game EXEs (as many mods do that) and what would be trojan-ing. Most people leave Steam running just about all the time, which locks down some of Steam itself, but not everyone does and all it takes is finding one good crash vector for Steam...
[2] Steam also seems to be several anti-practices here because as far as I can tell Steam doesn't ever bother to check if VC Redistributables or DirectX are already up to date on the system, it just spams the installers regardless...
* No app closure callbacks. You don't know if it's suspending or exiting.
* No "are you sure you want to exit? Save/Don't save" dialogs. If you close or crash pray your data was saved, and if it takes a long time to flush to disk...really pray.
* No minimizing/backgrounding to tray icons allowed.
* IMHO save/don't save dialogs are an usability antipattern.
* Tray icons are also something of a remedy of the past. They are now replaced by background operations and live tiles. I can see why those can be problems, I can imagine the usecases you would solve using those tools, but the new app model is build around a slightly different workflow.
But if you do not like the way to solve it as it is intended in the new app model, the solution is: report it/upvote it. If you tell your problems here, then some members of HN community will know it and understand it, but it is unlikely that it will be acted upon by Microsoft. For that you need to have your voice heard on their forums. (eg. feedback app, uservoice...)
Of course not, because it's supposed to also work on mobile. Does your iPad let applications prevent you from going back to the home screen?
You don't see the problem here? Why do I want the restrictions of mobile phones limiting my desktop applications?
Bashing UWP for advocating a different app model, and different UI design principles is like still using bash in 2016 because you are accustomed to ash from the 70s, and GUIs cannot go to start of line with Ctrl-A, thus saying they are inferior. Change has its positive sides and drawbacks, but in both cases it is mostly for the better.
Sounds like you have some misconceptions about the UWP/WinRT application lifecycle:
https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/a...
> The old system had defaults originating from the single user non-multimedia usecases left over as a legacy, but currently we have so many things going on our computers, that privacy/security needs a rethinking of old concepts to cope with new challenges.
I android has proven anything it's that sandboxed applications don't solve this problem.
This to me isn't a great trade off as it relies on the user invoking the process understanding the security risks they're taking, which is a tricky one.
Sure you can do more with sudo, but unless it's the default, most people won't
You're more likely to think twice when you open your flashlight app and it asks "Do you want to allow [Flashlight App] to read all your contacts?"
That's why there is such thing as system settings.
And yes, most desktop users are conscious when they work with files. Windows by default suggests "My Documents" folder as a target destination which is a pretty sane safe choice for all traits of average Joes.
Though you can't submit to store with request for that permission: https://msdn.microsoft.com/windows/uwp/packaging/app-capabil...
Personally I'd suggest that the trade off is whether the risks of global filesystems are worth it in productivity benefits.
For standard users (non IT-professionals) I think they are not and for IT professionals, in most cases, I think they are.
OpenSSL has had 22 vulnerabilities in 2016 so far [1]
Linux has has 336 vulnerabilities in 2016 so far [2]
[1] https://web.nvd.nist.gov/view/vuln/statistics-results?adv_se...
[2] https://web.nvd.nist.gov/view/vuln/statistics-results?adv_se...
Every time I visit family I get to sort out the files scattered around the hard disk.
Funilly enough, in her 70's now she's taught herself to use a computer and can manage documents in the file system.
People starting in a green field will build a web or a mobile app if at all possible. The cases where it isn't are basically games and what used to be called "workstation" apps: big chunky tools like SolidWorks.
Even Adobe have retreated to the cloud, although the tools still run locally.
If it had worked it would have been a smart move, but it was wildly over-optimistic.
My take is that Microsoft is in mobile for the long term and that its strategy has been to gradually migrate the target uses first addressed with Windows CE into the mainline of Windows and that Windows 10 is the realization of that strategy...we're back running Excel on mobile devices.
Windows Phone 7 was the first step in that direction. Windows Phone 8 and Windows RT were intermediate steps toward hardware agnosticism and away from Wintel strategies. I call it an intermediate step because apps for those platforms were [at least largely] forward compatible to Windows 10 and Windows 10 Mobile.
Let's just take a moment to remember Games For Windows Live here.
I'm very sad about how accurate this generalization is.
UWP isn't a mobile OS ported to Windows. The whole WinRT is an OS and WinRT is an API set confused things. Forget that there was an ARM tablet. WinRT means the Windows Run Time. It's a set of API's that are built with the Windows OS. The "they made it mobile" part was really a side effect of trying to move to a more managed execution model where the OS took a more aggressive approach to managing the execution of an app over it's lifetime.
That has certainly needed improvement since it has been released. The WinRT API set was and is limited to a set of API's that are governed by a security broker. Applications are intended to have an identity, that is a SID, and execute in a very tight sandbox ala Chrome or Edge. It's a good model that makes some of the traditional malware vectors very hard to exploit. (You can't call LoadLibrary, for instance.)
OK. Set that aside for a moment. The desktop bridge uses technology called App-V that has been available to enterprise customers for a long time. It lets you run an installer and it watches all of the things it does to a clean system. It then bundles all of those things into a single file. It provides shims to your code that, for instance, will intercept your attempt to write to a global part of the registry and directs it to a registry hive kept in the file.
What they did in the anniversary edition was include parts of AppV in Win10, and they built a set of technologies that help with the process of "sequencing" a Win32/.Net app. Your application still runs just like it used to. There is no emulation. If you want to use API's that are available in UWP you need to follow some guidance on adopting them. Some are less invasive than others. Its a tradeoff, but it's one that you get to control as a dev and you can share a bulk of your code between Win7 and Win10 builds that use the strengths of both platforms.
So, its a sandbox, but not an emulator. The AppX installation method is more like the ".app" model in desktop OS X where you have a bundle of things for your app. There are also new security model things that you can adopt over time to gain access to new functionality.
You DO NOT have to install AppX packages from the store. You can download them from the Web and double click on them or use powershell to install them. The store is separate from the app packaging tech and API set.
Your comment reads like someone who doesn't use Windows enjoying some schadenfreude at the trouble they have had over the last couple of years. You're going to need to get over that. They are getting their shit together in a big way. Yes their mobile platform failed. They have admitted that and moved on. They produce a lot of software for Android and IOS. You can develop native Linux software with Visual Studio now. They contribute to Linux, Mesos, and Docker. .Net is open source. They contribute to FeeBSD. What more do you want? No one is making you use their stuff. You have never had more options. Why do you feel like that for you to be doing better other people have to be doing worse?
I want Windows to remain the dominant gaming platform. But for this, UWP is completely heading into the wrong direction.
Can do a manual convert (https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...) or use the tool to create the appx then double click to install, I believe...
What I'd actually like to see is a new application model and set of APIs 100% focuses on games, in the original spirit of DirectX. The required API footprint for games is minimal and should be easy to sandbox.
None of the existing desktop or mobile operating systems are particularly well suited for games, writing window system glue code and input event handling is terrible everywhere outside of the game console world.
Only Microsoft cared about that in the early days of DirectX and before it's gaming focus shifted to the Xbox and Xbox360. We need a new DirectX initiative which fixes the flaws of UWP for games. We don't need one generic solution which is supposed to work for all application types, we need a couple of highly specialised APIs and specialised application models. As Windows8 has shown, one-size-fits-all doesn't work.
[1] https://msdn.microsoft.com/en-us/windows/uwp/graphics/visual...
His stuff is just worth watching anyway. Awesome Windows dev and ISO C++ content.
They've built up an enourmous reserve of ill-will that will take years to diminish. It wasn't all that many years ago that they were tangentially involved in SCO's last-ditch attempt to destroy Linux. The Win10 telemetry and forced-updates controversies are ongoing.
Everyone can see a possible future in which all the doors for shipping software to users' computers without paying 30% to the platform holder and submitting to their arbitary rules are closed. (The justification will be malware, of course). That day has not yet come, and it's not necessarily implied by WinRT, but it's a step in that direction.
BTW. That was mainly IBM and Novell that you want to be mad at. Microsoft made a licensing deal with SCO to license Unix. Wow. You really have to reach back on that one. You could have more reasonably chosen how they treated Netscape.
No one ever seems to mention that they invested in Apple at a time when that investment KEPT APPLE ALIVE. But what ever.
The telemetry. It bother you. It doesn't bother me.
The "Get Windows 10" app that people were complaining about? Fair play. That was crap.
I don't know what to say about the last statement. Ask anyone in computer security and they will say, yes it would be great if walled gardens weren't the best idea for getting trustworthy software onto customer systems, but right now it is. They all think that Android is worse than IOS. Platforms that are used by a billion people where you can do anything you want produce malware. There isn't a way around that right now.
Solve that one and you too can be a billionaire.
My feeling is that the "ill will" is more emotional than it is reasonable. I know lots of admins who made up their mind about Windows in the Windows 2000 and 2003 era. It's vastly different in 2016 and far better. It's hardly recognizable.
EDIT: OK OK. Babies may have been hyperbole. Toddlers. They were toddlers.
In re malware and walled gardens, I certainly don't have a solution, but I've been writing a chart of the extent of the problem: https://github.com/pjc50/pjc50.github.io/blob/master/pentagr...
Yes youre right the 'new' microsoft under nadella is much more accommodating, however I was forced into a place where I couldnt afford the problems the 'old' microsoft bought and it was more logical to adopt open standards. Since I switched to open platforms microsoft has really improved but pardon me if I stick with my open tool stack for the foreseeable future until i see any compelling reason to switch back. In other words, microsoft is now 'as good' as many open platforms, but there isnt really a compelling reason to switch back.
Still just sitting there running.
No need for pardon's. Use what you like that gets the work done. My instinctive flinch is different. We all have them. That's the thing, I don't want you to switch. I don't care. I love open source software. What I am saying is that they have a lot of effort built into backwards compatibility. And those solutions may not be the latest hotness, but you can still run them.
Them to open source and GPL all their software.
I want Stallman to give more care to the defense industrial base that produces computers than to making sure that the same defense industrial base has a free f*cking compiler to use on the computers it makes.
Windows is MIT licensed now?
System Center is MIT Licensed?
Visual Studio is MIT Licensed? (not core, core is not Visual Studio, it Github's Atom editor with a MS skin)
I believe I said ALL software not just some side projects
no windows is not MIT. nor is system center. PowerShell is. PowerShell DSC is. Their OMI broker for Linux is. .Net is. Asp.net is. Their Python tools are. The C# language is developed on video streams with the product team and the community. F# has been open source for a long time. They contribute to Linux, Mesos, docker, Hadoop, and other projects.
I wish that my side projects were as widely used as the C# compiler.
Why don't you just admit that there really isn't anything that they could do. If they did open source Windows you would read some comments written by other people about the code and "pronounce" it the worst code ever written. I can safely say that because here's the thing...YOU'VE ALREADY WON and it's still not enough. Open Source won. They were forced by the sheer awesomeness of it and the energy that people like you brought to open source development to adopt it and push it where ever they possibly can. TAKE YES FOR AN ANSWER. Is Windows OSS yet? Not yet, but that is coming. And when it happens you will still have something negative to say about it because this isn't about anything other than your emotional ties to this Microsoft in your mind that has been your favorite boogeyman for years. Guess what? There are actual boogeymen in the world, but focusing on a software vendor keeps you from having to face that. Every computer you buy validates and enforces the defense industrial base of the west. You capitalist infidel, you. All electronics, really, but computers in particular.
You want Visual Studio to be GPL'd? I want to stop flooding the third world with cheap weapons. They need water, not a text editor. Linux doesn't make them more free and Windows doesn't make you less free. It's a stupid privileged argument. Play with your toys and try to be nice, but don't tell me that your toys are more "right" than mine. That's just fucking stupid.
I have had entirely too much coffee, and it's probably time for a new HN account anyway. Cheers.
It's not a fork of Atom. It's independently developed text editor/light IDE which runs on Electron, chromium toolkit created by Atom devs to ease creation of desktop applications using JavaScript and HTML.
IMHO a modern OS should only come with a low-level window-compositor which just composes canvases, and leaves rendering (including UI) to the user code through a thin 3D API. Other than that: file system, sockets, input, audio, and a very simple main-loop application model, all as C APIs which don't try to be object-oriented, leave all the different language bindings to the user-side.
You are describing X11?
>A few months ago, during Build 2016, we announced the Desktop Bridge, enabling developers to bring their existing desktop apps and games over to the Universal Windows Platform (UWP) by converting their app or game with the Desktop App Converter and then enhancing and extending it with UWP functionality. This then enables the path to gradually migrate the app or game to reach all Windows 10 devices over time, including phones, Xbox One and HoloLens.
Seems to make the Store very backwards compatible, it can even convert VB6 apps: http://www.hanselman.com/blog/PuttingMyVB6WindowsAppsInTheWi...
Also if you want to go from exe rather than installer you can use makeappx directly https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...
Oh dude, this brings back some memories... but I have to admit, for long time there was nothing except VB6 if you wanted to put together GUI apps with very little code and a WYSIWYG GUI designer.
I've just checked on Windows 10, and yup, MSVBVM60.dll is still part of the OS install - the mind boggles. This is classic MS - providing support for as long as they can, where they can.
Of course I'm not sure how the UWP Bridge would work if your VB6 app referenced a bunch of old school .OCXs though, as typically even the self registering ones need to write to HKEY_LOCAL_MACHINE part of the Registry, which the Bridge docs say is a complete no-no.
I used form and image controls to made a pixel based tiled fighting game. Not an actual game engine. Just a horrible hack that actually worked and I was proud of it. It was one of those things that helped me get into programming.
(I still have a copy of it.)
Though you can also build one with a text editor and command line: https://blogs.technet.microsoft.com/nanoserver/2015/11/19/ha...
That's exactly the sort of thing I'm after, thanks. I hate it when configuration is hidden in favor of tooling.
I didn't mind NSIS (nullsoft of winamp fame), but it was weird to say the least. Install scripts were a high level, domain specefic variant of assembly...
Now I notice that probably 50% of the MSIs that I run are using the AdvancedInstaller dialog skins.
I wonder what barriers MS has in place to prevent that sort of piracy?
1) How good is the sandbox? I followed the links but how battle-tested is it? What if you put an already sandboxed Chrome inside UWP, does it basically use almost the same calls or there are some extra benefits? Besides FS isolation.
2) Can I browse the "sandboxed disk" (including registry files) and export everything? So I can make backups or restore it later.
3) Does it stop apps from installing intrusive things? Some bank plugins use like 30% of my CPU on idle, run a lot of services on startup, so I have no option but to use a VM.
I'm really curious about all of this and there's almost no hype around it. All I see is people talking about walled gardens, privacy concerns (that I have too), how they screwed in the past with GFWL, Windows 8. But downloading software from 3rd party sources in 2016 is just awful. I want the Linux package manager experience. I don't trust any 3rd party like Ninite, Chocolatey, and they have like 10% of all the software I need anyways.
Let's see if the third time I make this comment gets a reply
Also full trust vs app container here: https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...
If you know where to look, pretty much everything in a UWP app can be opened via file explorer. Check out the C:\Users\yourusername\AppData\Local\Packages folder
What next? What are the UWP APIs/functionality worth adding to an existing Win32 app?
The upshot is that by putting your software in the Windows store, there is a chance that you will gain new users that would have never found your product otherwise. It also removes some of your overhead considering that Microsoft hosts the software themselves, handling payment, storage, and bandwidth for you.
The biggest benefit would have to be copy protection. Copy protection is hard to do because MS has made it hard intentionally for both technical and privacy reasons. Also the people making these decisions at MS are also on the payroll of the installer companies who benefit from not having a workable and freely available alternative. And there was no insentive internally at MS to fix it because bonuses are tied to the new metro stuff.
If you're doing something mass market then 30% might be worth it. But if you're niche, which is MSs bread and butter, and stickiness, then it will not be worth it. Which is an idiotic position for MS to be putting people in.
I predict continued failure of the App Store which will erode Microsoft's dominance in the long tail. The only thing keeping me on Windows is WPF and legacy customers.
Personally for me as a developer, I think one of the biggest benefits to app stores is payment handling and updates.
The latter in particular is such a pain to get right traditionally on Windows in particular. You can either ping your server and nag the user to download an installer at startup or run a background process that periodically checks and installs updates silently. Neither is ideal.
As a user I also prefer the Windows store to the status quo because I can cleanly uninstall store apps. Traditional uninstallers almost always leave vomit all over my computer that doesn't completely wash away until I inevitably reinstall Windows.
For mobile: use Xamarin.
For desktop: use win32/.net so you can support pre August 2016 versions of Windows.
For Xbox and ARM where you also need support for desktop and mobile devices: use UWP.
For Desktop, probably still a better idea for new development to be in UWP directly instead of converting a Win32 app.
This isn't the "death" of UWP, this is a stopgap bridge to take the long legacy of old Windows apps and give them a new life in the UWP era, including making it much easier to migrate out of classic Win32/.NET for newer UWP APIs, one screen at a time instead of porting the whole thing at once.
The keyword here is probably "extending". I am not aware of what it really means, but I wouldn't be surprised if MS tried everything it could to get more developers on its UWP. And keep them.
It doesn't mean...whatever paranoid thing you think it means. Also, its a developer related thing. If you don't have a desktop app that you want to move to the store or bundle in an Appx package for distribution on the web, it doesn't mean anything to you.
Does this also include "allocate executable memory" (you need this if you write a JIT compiler)?
You may need to buy one if you distribute the appx outside the store and you want it to be automatically trusted? (As you don't need to distribute the appx via the Store or install via the Store)
If not then thank you, I would not bother to participate in a walled garden.
Is there any practical step-by-step guide on how to achieve this? Or at least any sample website that offers installable downloads in APPX/UWP format?
The last time I tried it wasn't possible at all without some PowerShell black voodoo scripts with some temporary certificates and other royal pain points rendering the whole technology totally useless. I could not even run my own appx apps because they should only be run "in container context".
UPDATE: Just tried to create a blank app, packaged it into .APPX and run it on my machine by double-clicking the resulting APPX file. Here is what I've got:
"Either you need a new certificate installed for this app package, or you need a new app package with trusted certificates. Your system administrator or the app developer can help. A certificate chain processed, but terminated in a root certificate which isn't trusted (0x800B0109)"
What? Totally useless. I've just compiled MY application on MY machine and I even cannot run it.
Why not replicate the UAC known/unknown publisher model? And those MS people are then curious why their latest greatest UWP/Store platforms aren't getting enough traction.
UPDATE 2: tried to run my compiled .EXE file without APPX packaging.
Here is what I've got:
"This application can only run in the context of an app container."
Duh. Universal Windows Platform they say? Conquer the world? Nope. It all stops at "the context of an app container".
UPDATE 3:
Settings -> Update and Security -> "For Developers" -> Developer mode ("Install any signed app")
Of course I did this. Does not work as described above. All I want is to run MY just-compiled app without the hoops in loops, for starters. Yep, installing a temp certificate probably would solve this but its a PITA because it expires and requires ceremony. Won't waste my time, sorry. See ya at the next MS Conf. Hope .exe files will be launchable again till that time.
P.S.: Sometimes I miss Sir William Gates
Or install your certificate in Trusted Root Certification Authorities
Or buy an application signing certificate from a Certification Authority
Or distribute via the Store which signs for installation for you.
Bad security is a feature. If platforms were secure against hostile applications, we wouldn't need app stores.
Because it is the typical anti-M$ conspiracy theory. It blames on "evil" what it can't understand.
Win32 is not insecure because they wanted to sell security. It is what it is because that's what made sense at the time, before Internet and viruses appeared, memory was restrained and virtualization and sandboxing were obscure techniques and processing power and memory were severely constrained.
The "could have been done decades ago" is not that simple. One way or the other it should imply in limiting direct access to resources by programmers. And, giving how big the Win32 ecosystem became, that's more political than technical.
If the resulting file can be distributed outside the Windows app store, the developer can avoid the appstore tax and retain access to a direct customer billing relationship. If signing of the sandboxed-app-installer is required, $100/year (or other tolerable fixed cost) is still better than a 30% tax on every sale.