Comment by stefan_
1 day ago
WinRT was technologically terrible (which immediately flows from "no one at Microsoft was actually using it to make anything useful"). But that wasn't even what sunk it - the whole requirements around "of course your WinRT app is going to be in the Microsoft Store^TM its the future" did that. The fucking store is a joke, and those requirements existed solely to boost a bunch of idiots internal careers.
The Windows Store thing was so terrible that I would argue the only good thing that came out of it was that it made Valve/Steam invest in Linux.
I still don't understand why the windows store search sucked so badly. It isn't like they had billions of apps. So why did it suck?
Most probably it was on purpose. MS is famous for the infighting of internal groups and how the management doesn't know how to control their divisions.
Correct for the Windows 8 and 8.1 initial versions, it was already quite good with UWP on Windows 10.
But then they rioted internally to kill C++/CX (the only time they had something comparable to C++ Builder), Project Reunion got announced and misused from the original goal, porting WinRT back into Win32 killed .NET Native as well, most of the key team members left to Amazon and Google, Azure or AI teams, the team is now mostly interns or juniors from Microsoft India, no direction, and is a mess, naturally.
I went from a WinRT advocate, to pointing out devs to stay away from it, this is how bad they treated those that actually believed WinRT could be it.
Part of the reason was that WinRT was aimed at tablets and other low power devices, where unrestricted Win32 API use could drain the battery too quickly. They were trying to put the genie back in the bottle to have more control in this new ecosystem, like Apple enjoyed on iPad, etc. Much of the weird signing and app store evaluation was to make sure your app used only the blessed APIs and wouldn't, for example, stay awake in the background listening on an arbitrary port and drain the little tablet battery.
Painful and nonsensical from a desktop standpoint but also kind of impressive in a way.
My favorite example of that was when WinRT app .exe files could not be launched from the command line. Only via some Windows Store voodoo dance with approvals, signatures and "security" that made WinRT for developers essentially a dead-on-arrival technology.
I would not be surprised if you still cannot launch a fricking .exe.
This was sorted out in Windows 10 with the unification of WinRT programming models under UWP.
Nope, it wasn't solved in UWP days, neither it's solved today.
To satisfy my interest, I've tried creating WinUI app (aka UWP/WinRT) in Visual Studio 2026. And this is what I've got on the first app launch after compilation:
"This device needs to be set up correctly to develop this type of app for Windows. If you don't, then you can't install and test your app before you submit it to Windows Store"
I don't want to install/submit, I just want to be able to run my fricking .exe.
Why you call this issue solved? It's still right there - the same voodoo dances and disillusional expectations of subordination to Windows Store.