Posted by naves 1 day ago
I got to the point that I could create windows and controls, and had a basic message loop working.
I then started dabbling in painting in non-client areas. It was buggy and didn't work well (my fault), but then I could see 2-3 different Windows UI styles competing to draw the window chrome.
The amount of crumbs hidden under the Windows carpet is incredible.
I still think WinForms is one of their best UI framework. As for WPF, intentionally avoided it since day one. I’m not fiddling with no XAML.
Has it become unreasonable to use an image editor for anything? At least to stamp some readable text on top of your slop??
He's claiming Microsoft pitched "WitdFT" (sic), "HTMLAl5" (sic), and "C++" sonuitaneously (sic) at Build 2012.
HTML5 was released in 2008 and the C++ reference was released in 1985. How is this acceptable?
If Microsoft hadn’t been preoccupied with a failed mobile bet then this wouldn’t have happened. It’s a lost decade followed by a (much more successful) cloud pivot. The reason desktop is ignored is because it can be. No one is eating their lunch on desktop.
People who play this corrosive game either refuse to believe that they are at fault for not changing what they were doing at that time or speaking up about what they were observing then, or they know they're at fault and want to deceptively distract us from that fact. Either way, ask yourself this: "Aren't they sorry?" If they're not, just move on.
> 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.
"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.
It's true that there is no great answer for how to add capabilities and sandboxing after the fact. But what Windows did was build an incredibly restrictive sandbox and then tell everyone who couldn't accommodate even one of the restrictions was "sucks to be you". The result was that developers, when confronted with "all or nothing" for Metro-style apps, were forced to choose nothing. It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP, and in the latter case, was specifically exempted from the Windows RT restrictions to continue using Win32 on that platform.
If there had been a better strategy for easing in UWP technology, we might have seen better progress on adoption of Windows Runtime APIs and capabilities so new programs could gradually move toward the new technologies and away from HWNDs. Unfortunately, the technical barriers that were put in place between Win32 and UWP are so large that progress toward breaking them down in the Windows App SDK has been slow.
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...
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.
Then there's a lot of legacy stuff that needs to continue working because otherwise you end up with a non backwards compatible windows.
Then you have to get everyone at microsoft across all their bajillion products to change the UI from Task manager to the 5th level of settings for some obscure ODBC connector.
It's not going to happen I suspect
I wonder if we attended the same conference session!