undefined

points

[-]

The most offensive part of the Sinofsky response is this part:

> WinRT (2012) - it (or the embodiment in Windows 8) failed in the market but it also showed both the problem and potential solution to building for new markets while respecting the past

I can't express how wrong this is. WinRT was the most destructive thing that the Windows team ever did to the OS. It drove a hard stake into Windows, splitting it in half and declaring that anything previous to Windows 8, oriented toward desktop, or using primary input through mouse and keyboard over touch was dead. Microsoft basically told all existing Windows developers that if they weren't building a new, touch-oriented, mobile-style app specifically for Windows 8, they didn't matter and wouldn't get any support whatsoever, which is exactly what happened every time they broke existing desktop functionality. Calling this "respecting the past" is a crass insult and taking no responsibility for damaging the Windows development experience and accelerating development away from native Windows apps.

by WorldMaker18 hours ago|

parent|

[-]

I think for Sinofsky the "respecting the past" refers more to WinRT was/is still just Spicy COM under the hood. Most of the article as I read it is about how .NET was a mistake for Windows UI development and a return to (Spicy) COM its savior.

by ack_complete6 hours ago|

parent|

[-]

That might have been more significant had the Windows Runtime not been effectively locked off to Metro-style apps. You could technically use it from a desktop app, but almost all of its functionality was only allowed within a Metro-style app, often due to requiring a core window or package identity. Even today the vast majority of useful WinRT APIs, including the entire UI system, require UWP or package identity.

by WorldMaker6 hours ago|

parent|

[-]

Package Identity isn't that different from Signed COM Registration of the ancient past. Microsoft built up a lot of dislike from it by building it "sandbox-first", but the core of it still isn't that different from COM's ancient footpaths, at least to the COM diehards that hate .NET and didn't learn near enough from .NET's battles with the same things in terms of package signing, CAS (Code Access Security), and the GAC (Global Assembly Cache).

"Sandbox-first" even made some sense as a direction to work because it is harder to add a sandbox after the fact than to start with one, which is one of the core lessons learned from XP trying to sandbox some of the insecurities in Win32 and getting caught in a lot of complications. (The "sandbox-first" of UWP wasn't even that different under the hood from the XP "sandbox" of Folder/Registry Redirection, just a little better hardened.) Microsoft needed a lot better messaging up front if they had expected to allow more apps to leave the sandbox eventually. But Microsoft probably did believe the UWP sandbox was a better and safer experience for consumers.

But yeah, what's left of Package Identity outside of the sandbox feels like it includes several classic mistakes from .NET's CAS/GAC era, and also seems to point out that Sinofsky was wrong about WinRT "respecting the past" when it failed to learn from that era because it didn't trust .NET's history.

by hyperrail5 hours ago|

parent|

[-]

There are still some things that are still locked in the UWP world that I wish were not.

For example, Windows classic desktop apps still have no equivalent to the UWP app lifecycle. Your UWP app's processes can be suspended and resumed without you writing code to force the suspension and request when to be resumed later. Instead, you are expected to appropriately handle event notifications for suspend, resume, and the app entering and leaving background state.

This system-managed UWP app lifecycle makes life harder for UWP app authors, but I think the net win for battery life is much better for the user experience, which is why mobile apps operate the same way. Yet the docs for the Windows App SDK, which is supposed to bring the best of the UWP to desktop apps, explicitly say that WinAppSDK apps control their lifecycle just like other desktop apps, and the only power friendliness in the WinAppSDK API is voluntary (aka no one will use it). [1, 2]

I'll probably write more soon in response to other parts of the original link's comment thread. Overall, I feel like UWP is being unfairly maligned here, and that while its introduction was unforgivably arrogant, Steven Sinofsky is also right that it was daring and necessary to fix the mistakes and outdated decisions of 16-bit Windows and Win32.

[1] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...

[2] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...

by WorldMaker3 hours ago|

parent|

[-]

Those are some good points, and I especially loved that lifecycle management in the era where I used a lot of Windows 8 apps. Even on a Desktop with apps filling up my screen still seeing some of them pinned to 0% CPU most of the time (while I'm multi-tasking) in Task Manager was a delightful magic. I also agree that was one of the best parts of the UWP sandbox and one of the biggest shames when Microsoft had to figure out how to allow sandbox breaks that they couldn't find a way to make the lifecycle and other smarts parts of the sandbox more opt-out by default rather than "opt back into the full sandbox". Of course needing to opt-out by default was one of the reasons developers hated the sandbox in the first place. It's a marketing challenge no matter how you slice it.

That relates to some of my criticism that maybe UWP could have used more .NET veterans because that was one of the problems with the CAS sandbox. For the most part the CAS sandbox was "opt-in" and yeah software developers through ego, hubris, and everything else will most often declare "my app/library is a special snowflake and needs access to everything!" So even if things opt-in to additional security controls like CAS, no one tests or builds for Production in a CAS sandbox so even things that claimed to support CAS threw runtime exceptions all over the place to the point no one could trust CAS to the point were CAS died for being practically useless overhead because no one both opted in and knew how to test it.

UWP had a lot of good ideas. It's insistence that it didn't have much to learn from .NET's mistakes was not one of them.

by jiggawatts20 hours ago|

prev|

[-]

“Retired general criticises the Pentagon” is practically a trope.