Microsoft had a lot of great talent suffering from a lack of leadership and coherent vision. They foreshadowed everything wrong with Big Tech today.

At this point one must ask if Microsoft is still a software platform company - whether their products form a substrate where an ecosystem can form and build a coherent software environment for the users of their platform.

Microsoft used to be the Windows company (after being the BASIC company, then the DOS company). Then it became the Office company. Now it’s SharePoint and Office365 and Azure, a utility. Windows is a relatively small part. Office is both desktop and web (and spacecraft, where they have two versions of Outlook and none of them works). If you are confused at this point, so am I. There is no vision as to what Microsoft is. If Satya Nadella knows what Microsoft is, he isn’t communicating it properly. It’s not Azure, because there is also Office and Windows. And on-prem server products. And a line of hardware products. And stores (do they still exist?).

Your post is touching on a key question: why write a Windows-specific app?

I'm a developer who has built and published several apps. I want the biggest possible audience for those apps. Why would I limit those apps to Windows? (Or even to any single platform/OS?)

Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't make sense.

Just build for the web. You can package web apps for all the major app stores using PWABuilder[0], no Electron needed. Just fast, lightweight apps distributed by app stores and accessible from the web.

[0]: https://pwabuilder.com. Disclaimer: I work on this

If I'm writing Windows desktop GUIs I still stick to WPF. Might be Stockholm syndrome but I quite like it.

I don't see the reason to use any of the new ms ui frameworks. Especially if ms themselves don't even really use them.

As far as I know visual studio is still a WPF project so I'm not super worried about it no longer working.

At the same time VB still works and runs, so they don't always rug pull.

Since that article is a response to this one, we'll add a link to it in the toptext above. Thanks!

WPF looks much nicer. Personally I find it hard as hell to debug.

Winforms just work, and have a well defined set of behaviors. It does not matter that they do not look as nice for most people.

That’s not so bad. I still stick to win32

They might have forgotten to pull that rug.

MS has never been a software platform company. That's the fundamental reason behind the issue the article talks about.

MS has always been a software application company. Windows was never anything more than a way to sell MS applications--and Windows 3.0 and later wouldn't even have existed in the first place if IBM hadn't dawdled so long over OS/2. Even in the MS-DOS days, when MS was reaping the benefits of IBM's previous bonehead decision to hand the PC OS market to them, MS was selling Office applications--on the Macintosh.

The basic Windows API, in all of its many incarnations, has always been a second-class citizen; MS Office applications have always done their own things that other Windows applications couldn't do without using undocumented features that MS could change at any time (and often did). One could argue that the only reason MS even allowed third-party Windows developers to exist was so that they would, in the words of one of PG's essays, do market research for MS. When a third-party dev came up with something that got enough traction, MS would simply incorporate it into their apps.

He immediately said they never did make a decision, so probably that indecision.

Having said that, this article feels like AI slop to me. Couldn’t get through it.

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.

It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms. Or why the HTML/JS app model in Win8 never really took off.

I was in DevDiv during his great WinRT push and the overall feeling I remember was that the guys in Windows had zero clue as to what the devs actually wanted, but were hell bent on scorching all the ground that wasn't theirs. My team actually did some prototyping for Python/WinRT support, and we had it working to the point of the visual WPF designer in Visual Studio even. Unlike JS, it was full fledged - you could use anything in WinRT same as C#, extend classes etc, while JS limited you to a "consumer" surface of the API. That prototype was killed because Windows (i.e. at the time = Sinofsky) said they didn't think developers cared about anything but JS so they didn't need another high level language.

It was also when Windows was aggressively pushing their Metro styling on everything in the company, sometimes to ridiculous lengths - e.g. Visual Studio at the time "aligned" with Metro by, I kid you not, making the main menu bar ALL UPPER CASE so that it looked like Metro tabs! You can still see the blog posts announcing this "feature" when it shipped in the first public beta of VS 2012, and the comments on them.

And then there was Windows RT (not to be confused with WinRT, because Microsoft product naming!). Aka the Windows-on-ARM that ditched decades of backwards compatibility because Sinofsky decided that rebooting the ecosystem is the only way to compete with iPad or whatever. What actually happened was that the users went WTF because none of their native apps - which, contrary to his take, were very much alive and kicking! - worked there, and devs went WTF because they were told that they'd need to rewrite everything yet again in some new thing that was kinda sorta but not quite like WPF, because Windows just hated .NET that much and couldn't accept that the devs liked it over their stuff. So the app store was a barren waste, and without apps there would be no users.

Some of the technical details in there are plain wrong, too. For instance, .NET 3.0 actually shipped in Vista, contrary to his claim that it was shipped in Win7 (and that it was the first time .NET shipped in consumer Windows - in fact, that would be .NET 1.1 shipping in WinXP SP1).

Entirely AI. I just can't with this style anymore.

> It's worth noting though that Apple is on a similar trajectory and is now in a very nearly as bad position given all the serious issues with SwiftUI and how badly it has fragmented/degraded Mac desktop application development.

Apple (and Next before it) have been iterating on Appkit/UIKit for three and a half decades.

Now they have added SwiftUI as a second option and have been iterating on it for a bit over half a decade.

This is in no way similar to Microsoft creating and abandoning another UI framework every couple of years.

If Microsoft had been steadily improving Win32 all these years, where would it be today?

Qt/Win is enough to get the job done. Not always pretty, but it works. I used to be somewhat ashamed I never learned the actual Win32 API to write native apps, but now it looks like that was time saved. This is a great article.

You have managed to concisely summarize the progress of Windows UI development for the past 15 years, yes.

Just have a look at the final picture if you're unsure if it's slop

Thank you!

It is a wrapper, but it's not quite on the same level as MFC. MFC really is a thin wrapper, almost 1:1 in most places. WinForms is more like VCL or VB6 in that it uses Win32 where it can but doesn't design around it, so in practice it's more high-level.

I agree with the thesis of your post, but where we differ is that I think both of those were (are) bad things. Both web apps and vibe coding are causing the market to be flooded with low quality software, not only making the market worse but also giving future generations fewer examples of well-made software to look up to.

The problem with things from the Linux world is that they never reached the height of commercial desktops to begin with.

If you really enjoy worse Windows XP UX with hamburger menus in recent versions then by all means go ahead, it does function.

Same here. Also the benefit of a visual Editor in Visual Studio is just Premium. Windows.forms also allow all those „modern“. Takes on ui either with ownerdraw or some grids/hand layouting.

SDRPlay is using Avalonia for its SDRConnect desktop UI. That's the one native application based on Avalonia I've spent significant time in.

It's ok. I give it pretty high marks. There is a good deal of "lowest common denominator" in it, naturally due to cross platform abstraction. But, it's generally nice, and commercial licenses are affordable.

Nadella thought he could take the reins and start yelling “Cloud! Cloud! Cloud!” and that would be successful. He doesn’t have a strategy and now that’s becoming apparent.

I used to get hung up on this native vs web thing. But when it comes down to it, it's just one renderer or another unless you're actually drawing the controls yourself pixel by pixel. The sticking point is following the system style / theme. But all the popular desktop OSs seem to have deviated on this so much themselves I'm not sure how important this is.

Microsoft was so focused on the enterprise they forgot that enterprises are made up of individual users.

Any trade-off that favors the enterprise in lieu of the user actually benefits nobody in the long term.

I flagged the post, don't even care how accurate it is. Go send your AI slop to /dev/null, folks.

Definitely not, since it actually takes quite a lot of red tape to ship something as ancient as MSVBVM60.DLL in Windows 30 years later, and guarantee that it is still working.

It's just that it's a piece of tech from back when Microsoft corporate dominance on the desktop was at its peak, and many large companies bought into the then-current tech stack, including VB6. So now Microsoft is stuck maintaining it because those are the customers that bring consistent revenue.

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.

> It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms.

Yeah, he's talking about WinForms like it was a whole new thing, but it was a very transparent OO layer over Win32 and extremely similar both to VB and Borland Delphi. It was one of the reasons why .NET survived at all when Linux servers became the default option.

Often kind of person who makes such mistakes is the kind of person unable to learn from them. The post by Sinofsky is exactly as I imagined it would be.

I have always been tempted to use WPF but I’m reluctant to learn a whole new language for side projects. Especially nowadays C# seems to be as huge as C++. Oh well maybe I should grit through the beginning phase.

How do you reconcile this with their history of bending over backwards to achieve backwards compatibility for third parties?

> Apple that doesn't allow to ship its own UI libraries

You can just render on a canvas like flutter and KMP. Most end users don't care

Microsoft was a language company at the start - they had a huge share in 8-bit computers and their BASIC made into the ROMs of almost every computer sold in the 70s and 80s. Then they branched out to applications, with little success (I remember Multiplan on CP/M, DOS, and Mac). When they started selling PC-DOS and MS-DOS they had no applications play to speak of. Office only came much later, and the apps that appeared for Mac, Word and Excel, were ported to Windows starting on Windows 2. Word for DOS struggled in the market and never reached a significant share.

The summary of various frameworks and languages available is very concise and informative though.

I found the article itself very informative and not particularly ai-tastic. But then I got to that infographic at the end. Holy smokes was that disappointing. It seems clear they didn't even bother to read the captions the AI scribbled.

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

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?

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.

Sinofsky kept talking about how many devs were making apps in JavaScript and how they would just be at home in Win8. This was before React, ES5 (no native classes! or promises!), etc- jQuery was still very popular and SPAs were extremely rare. He completely overlooked how dependent many of these devs were on their servers- Python, Ruby, PHP, etc.

(disclaimer: I was an individual engineer in the Windows division during the Windows 8 project, i.e. reporting through Steven Sinofksy)

I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs and how it has made Windows' developer platform much worse over the years, but I have always thought we had a better relationship than that, since my group's product was the main reason for yours for many years, and your group delivered so much for us in turn. Clearly your side had at least some reason to see things differently. On behalf of all of us, yes even up to stevesi, I'm sorry.

Now let me completely undermine my apology by nitpicking your comment :)

[continued in my replies to this comment]

How is he dunking on .net?

I think one of his main points is server .net was (and is) great.

But the UI part of it was cloudy.

I see it as complimentary to the post not contradicting it.

> making the main menu bar ALL UPPER CASE

I remember that. Especially silly.

> Windows RT (not to be confused with WinRT, because Microsoft product naming!)

The gold standard will always be "Xbox one series X", designed to be confused with Xbox one series S.

Windows RT had one other anti-consumer and anti-developer feature: it was locked down like a Chromebook, so you could only use Store apps on it.

It seems Windows division has too much power and they used it to break their things.

Also, Windows division is shipping a subpar product now.

In a sane world developer division and Windows division would think things together, developer division would produce the tools and the same tools would be used by Windows, other Microsoft products such as Office and third party developers.

Why that doesn't happen at Microsoft, I don't understand.

And I don't understand why Nadella doesn't do anything about it.

This makes sense, because even in the best times Windows was not the biggest money maker for Microsoft, it was Office. So MS was never fully behind Windows, it was only the means to an end, which was selling the most software for enterprises.

It starts out alright, and then ends with a pile of classic Claude-isms and an unreadable slop graphic. Like the author got bored of writing it halfway through.

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.

Cloud is now massively larger than any other part of Microsoft. It's why he became the CEO in the first place.

He maybe never had a strategy for Windows but he wasn't hired to have a strategy for Windows.

yea there's so many ways through this now. golang and wails is great, rust and tauri is great. both seem to not feel like the slug that is electron because they just use whatever os native web view your os has.

for the dedicated more native stuff dioxus is kinda cool if you don't want a web stack in the mix.

i'm enjoying golang and wails though paired with whatever front end i want, all apps i've made perform execellent on windows. bottom line = yeah i can't really think of a scenario where i personally would ever write an app for windows specifically.

i, like you, used to get hung up on native vs web framework. i'd encourage you to give it a go, possible you cede that mayhaps the native thing isn't as important as you thought.

I think you should look at the graphic. It's riddled with inaccuracies and nearly-unreadable spelling mistakes and mangled typography. I think that's plenty of a good reason to flag it.

I think it really abuses the assumption of good faith and the default to generous interpretation, because it forces you to divorce the author from their own published work in order to view them seriously. I suspect most of the comments here are generously ignoring the included graphic. But in the most generous view possible, the author is fine with publishing wildly inaccurate statements.

I think this makes HackerNews much worse, and posts like these should only be flagged.

They thought after V8 the performance was going keep improving and reach native speeds, they didn’t understand that the major performance wins were all upfront and it would hit a wall.

This was sorted out in Windows 10 with the unification of WinRT programming models under UWP.

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.

> And then there was Windows RT (not to be confused with WinRT, because Microsoft product naming!). Aka the Windows-on-ARM that ditched decades of backwards compatibility because Sinofsky decided that rebooting the ecosystem is the only way to compete with iPad or whatever.

It's important to remember the specific reasons why Windows RT 8 chose to not support third-party desktop apps. The most important aspect of "iPad compete" that we wanted on Windows for ARM was not "all app UXes look and work well on touchscreen tablets" but "you can't ship malware, not even by rebuilding your x86 malware from source." Thus, every 3rd party app on Windows RT would have to live in the AppContainer sandbox that UWP apps are in by default, and the requirement that you ship through the artist formerly known as the Windows Store would be a second line of defense against malicious apps. And with the forced-enabled Secure Boot, subverting the user-mode controls by secretly installing a bootkit would be hard even with physical access to the PC.

Even within the Microsoft world only, Windows Phone 7 had proven the success of this approach of locked-down apps only available through an app store that checked apps on submission and afterward for security. It was not unreasonable to think that similar lessons might also benefit users of "big" Windows, which is why Windows 10 and 11 have the opt-out "S mode" which defaults to the Windows RT restrictions.

I do wish though that Windows 8 had learned different lessons from WP7 (about which more in another point).

> What actually happened [re Windows RT, but I think the point applies to UWP in general] was that the users went WTF because none of their native apps - which, contrary to his take, were very much alive and kicking! - worked there, and devs went WTF because they were told that they'd need to rewrite everything yet again in some new thing that was kinda sorta but not quite like WPF, because Windows just hated .NET that much and couldn't accept that the devs liked it over their stuff. So the app store was a barren waste, and without apps there would be no users.

The fact that UWP XAML was its own new thing and not a extension of an existing Microsoft GUI app framework like WPF was not necessarily a "we hate managed code" thing, or even a "we hate those guys who invented managed code and want to screw them because we're Windows" thing. After all, .NET managed code had equal access to UWP through the .NET WinRT projection!

And to me at least (I didn't work on UI-facing stuff in Win8), it was absolutely conceivable that UWP could have just delivered Windows Phone 7 Silverlight's version of XAML to native code apps, with a thin adaptation layer to let even unmodified WP7 app binaries run on the desktop Windows .NET Framework with the WinRT projection and to allow slightly modified WP7 apps to look good in landscape mode on both Windows 8 and WP8. If we had done that instead of making UWP XAML its own thing, and if we had integrated the Windows Store with the Windows Phone Marketplace from the beginning so that Windows and Windows Phone apps could be sold as variants of each other through a single Store/Marketplace product entry on Windows 8 GA day, then I think we could have brought a lot of people forward who were already making good WP7 apps, and the Store wouldn't have been so empty.

Furthermore, IIRC much of the original UWP XAML implementation was done by the original people who built WPF and Silverlight the first time, and they would have known what they were doing in separating UWP XAML from Phone Silverlight. That they didn't go in the direction of extending Phone Silverlight was not necessarily shortsightedness on the part of provincial Windows people. Maybe they thought Phone Silverlight actually demonstrated fundamental limitations of WPF or Silverlight XAML or the Silverlight "coreCLR", or they wanted to make breaking changes as lessons learned from Phone Silverlight, which was put together about as hurriedly. (Windows Mobile 6 -> Windows Phone 7 first previews = 1.5 years; Windows 7 -> Windows 8 first previews = 1.5-2 years, tending toward 1.5 years if you account for the frantic re-planning after iPad came out in early 2010.)

> It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms. Or why the HTML/JS app model in Win8 never really took off.

At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework.

Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that.

So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.

> I was in DevDiv during his great WinRT push and the overall feeling I remember was that the guys in Windows had zero clue as to what the devs actually wanted, but were hell bent on scorching all the ground that wasn't theirs. My team actually did some prototyping for Python/WinRT support, and we had it working to the point of the visual WPF designer in Visual Studio even. Unlike JS, it was full fledged - you could use anything in WinRT same as C#, extend classes etc, while JS limited you to a "consumer" surface of the API. That prototype was killed because Windows (i.e. at the time = Sinofsky) said they didn't think developers cared about anything but JS so they didn't need another high level language.

I think the real mistake there was not so much that a particular projection of the Windows Runtime was stopped, but the more general idea that developers should be forced to consume what became known as the Universal Windows Platform or author custom WinRT components through only Microsoft-made WinRT projections.

In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012". (Martyn Lovell's Build talks on the origin of WinRT were a notable exception to this.) This discouraged people from using their existing COM skills to develop Metro-style/UWP apps or to gradually adopt features from UWP APIs that were accessible to them in their existing desktop apps. Other people have written that "WinRT=COM" thinking is actually a bad idea because it forces people to deal with COM and its more annoying ideas (separate IDL etc.); I disagree because we should have reached out to people who live in COM world to get a ready developer base.

That mistake was a key part of the still larger mistake you touched on of trying to make the UWP and desktop worlds 2 completely different developer platforms that happen to co-exist on the same desktop edition of the Windows OS. That was the key "we didn't listen to developers" mistake that set up UWP for its market failure. Another example: Even today, you can't adopt the battery-friendly UWP app lifecycle using Windows App SDK, which is supposed to be the UWP successor for desktop app developers. So much for WinAppSDK (or indeed UWP/Metro-style apps in Win8) enabling a true no-compromise user experience.

It took real tours-de-force like Kenny Kerr building C++/WinRT and blogging about it, Raymond Chen blogging about using WinRT APIs through the unprojected "ABI" interfaces, or the VideoLAN organization building a Win8/Win10 UWP version of VLC in C, to get the word out that the UWP world wasn't some alien thing with dark magic that only Microsoft wizards had full access to. And it doesn't help that the wizards really do have a few special powers that they jealously guard even now.

> It was also when Windows was aggressively pushing their Metro styling on everything in the company, sometimes to ridiculous lengths - e.g. Visual Studio at the time "aligned" with Metro by, I kid you not, making the main menu bar ALL UPPER CASE so that it looked like Metro tabs! You can still see the blog posts announcing this "feature" when it shipped in the first public beta of VS 2012, and the comments on them.

fair. but that struck me as strange even then. if anything, visual studio should have adopted the all-lowercase typography of the original metro-style design language from zune and windows phone 7, not AN ALL-UPPERCASE ONE.

Perhaps that was just another way that Windows 8 Metro-style apps' design and developer platform was like Windows Phone 7's Metro style, yet different in seemingly gratuitous ways. That is something I would attribute to internal Microsoft politics. Steven Sinofsky and Terry Myerson (leader of Windows Phone at that time) never really got along, and in the Microsoft philosophy of that era where engineering divisions were completely locked down from each other by default, that rivalry would have discouraged what little natural collaboration would have happened anyway.

Ironically, Office was the original poster child for Microsoft reinventing it's own widget toolkits, even back when Microsoft had a coherent visual design and developer story.

It's that Nadella doesn't really care about Windows, even though the kernel is the root of Azure. In addition, all the newer gui frameworks abandoned RAD interface. That is what made and still does make Winforms and WPF popular.

Nadella took the reins in 2014 and the stock has 10x’d since then. In the same timeframe, the sp500 has 2.5x’d. Sounds pretty successful to me?

The DOM is very ill-suited for most UI. Too complex and lots of missing features. It’s a whole bag of unneeded code and the resulting UI doesn’t fit anywhere.

The inconvenient truth here is also that following the system theme is an anti-feature for most apps. On the desktop, you want your app window to be recognizable at a glance, meaning the primary color should be the brand color, etc.

I currently have open Chrome, Spotify, Discord, Aseprite, and Zed. All of them look completely different, and that's actively helpful for me, the user.

It's nice to follow the system's light/dark setting, and obviously the behavior of basic UI controls should be unsurprising, but beyond that there's no point in "consistency".

He had a strategy and it worked very well. But every strategy must be updated. It's basic BCG matrix stuff every MBA graduate knows by heart: sooner or later your star product becomes a cash cow and then a dog. To keep your company growing, you need to identify your next potential stars among question marks, boost them with cash from the cash cows, put competent managers in charge and remove those who get in the way.

Gates did this with Windows, Office, XBox among other things. Ballmer failed to do this this with Windows Phone. Nadella did it with Azure, but he needs to do it once again with AI. You can see that he's pushing hard with Copilots everywhere, what's missing is a manager that has a coherent vision of what AI at MS should look like. ScottGu is in charge of both Azure and AI at MS, but I don't know if he can deliver.

The end state of genAI is that the end user is the enterprise

Crucially, at enterprise sales, those who make putchase decisions are not the actual users (except maybe for Outlook and Excel). They sometimes play golf together with vendors though. This is how stuff like MS Teams of Oracle Forms gets sold: it checks all the compliance boxes, has support, an SLA, "is industry strength", etc.

> Windows RT had one other anti-consumer and anti-developer feature: it was locked down like a Chromebook, so you could only use Store apps on it.

That was at least in part due to the aforementioned obsession with iPad and generally mobile. One thing that Sinofsky is not wrong about in his post is that the classic Win32 app model is not conductive to good battery life - there's very little there to properly handle things like automatic background suspension or low-power push notifications. WinRT was designed with that in mind, but that would make no difference if the apps would just ignore it, hence the heavy-handed push for WinRT apps only (AFAIR it wasn't restricted to Store, although you had to jump through some "developer mode" hoops to deploy apps directly).

The UI part is exactly what I meant. WinForms was a godsend for professional developers making line-of-business apps, because previously if you used first-party dev tooling, you either had to deal with the considerable limitations of Visual Basic, or you had to deal with MFC that was low-level enough that all the things that were tedious about Win32 remained tedious. In comparison, Borland had Delphi, and there was a good reason why it was so popular back in 90s and early 00s, and why Microsoft ultimately acqui-hired its main designer specifically to work on .NET (and it very much shows in the design of both C#, which owes as much to Component Pascal as to Java, and of WinForms, which is so similar to VCL).

With WinForms, we actually got something that was convenient without shackling you. And the whole cross-language story was great, too, especially around .NET 2.0 - with C++/CLI you could very easily wrap any random native code C or C++ library for consumption from .NET, with end-to-end integration in the build system, IDE etc.

"Unreadable slop graphic" xD

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.

If your only metric is stock price, yes. That’s the value proposition of enshittification.

In theory, the market should be pricing in based on future potential. As it has become increasingly clear this past decade, the market is not rational.

Sure, but how much of that had to do with the design and implementation of Windows? You know, the OS that runs half of the modern economy. Microsoft is just milking it without a coherent vision.

Cloud was taking off at the same time. Anybody in his spot would have been successful.

I agree with most of that. To be charitable to Nadella, at the time he first came into the role, Microsoft needed someone yelling "Cloud! Cloud! Cloud!" because the company was certainly behind folks like AWS. But for a long time he basically stopped there. Office migrated to the cloud and they pushed out Azure. Then he went on the AI rant and they decided that putting AI into everything, whether customers wanted it or not, was "the next thing." But now we're learning that Azure is a steaming pile of crap with customers leaving, and this article about GUI strategy shows they don't have an application development strategy. Everybody is fed up with Windows. Everybody is fed up with all the numerous "CoPilots." You actually have regular people investigating moving off Windows to Linux desktops. The one thing that Microsoft did exceptionally well through the 1990s and early 2000s was keep enterprises and app developers moving in the same direction. They bent over backwards to keep old Windows 3.1 applications running even on Win32 systems. That all ensured that nobody questioned whether they would work with Microsoft. They were the default and they commanded huge market power because of it. But that's all changed, and they have nothing to replace it. With everybody starting to ask questions that Nadella doesn't have answers for, it's going in a bad direction. Nadella needs to call his EVPs to account and force them to make some hard decisions about what lives or dies and then pressure test the resulting strategy with his customers, both old customers and potential customers. Surely, cloud and AI are a part of that future strategy, but he needs to figure out the rest of it.

This. So often features to use system colors can cause apps to be unreadable or just look like crap. The first time I get a bug report that people can't read something I will lock the colors the down, I just don't have time for that.

Who says the system theme is well designed at all? Back in the 1980s you could count on most text color combinations on a Commodore 64 or an IBM 3279 or a PC with a CGA working.

Today it is absolutely normal to type

   ls

on a Linux machine out of the box and if you are running X or Wayland some of the file names are dark blue on a black background and completely un-readable. To be fair, if you are logging into a Linux machine on Windows with ssh on CMD.EXE or most terminal software you get similarly poorly chosen colors. (To be fair, MacOS does do better!)

As a web developer it pisses me off because I am expected to follow

https://www.w3.org/WAI/standards-guidelines/wcag/

and regularly my management gets legalistic looking documents from customers complaining that we only have 6.5:1 contrast on something and you know what I do... I fix it. I wouldn't send anything to my tester that was unreadable and if I did I'd expect her to put in a ticket and I would... fix it. When MUI computes the coordinates wrong and something draws 20px right of where it should be... I fix it.

Whenever I've put similar tickets to the various parts of the Linux desktop mafia they close it as "won't fix" and often give me a helping of verbal abuse. Even Microsoft occasionally fixes something (even if half a decade late) and their people are polite.

Why don't we have more great UI toolkits for the canvas?

This is true until it isn't though. Blackberry was doing great with enterprise users until people refused to give up their iPhones even at work.

The main reason Win32 can't handle automatic background suspension or low-power push notifications is simply that those features haven't been exposed to it. There's nothing preventing a Win32 program from receiving those types of notifications and then being force-ended by the OS if it doesn't respond in time.

When I first started porting programs to Windows ARM64, I didn't have an ARM64 device and had to test in QEMU. It ran extremely slowly, probably 1/50th of real time. All UWP programs like Calculator ran like a slug. But which programs still ran reasonably? Classic WinDbg and Task Manager. Two programs that were still plain Win32.

There are significant issues with Win32, namely its lack of a permissions and isolation and lack of hardware acceleration in the old windowing UI (User/GDI). But the idea that Win32 is inherently power inefficient is, IMO, just BS. Its roots go back to CPUs that were orders of magnitude slower than modern CPUs and there is nothing difficult about making a Win32 program that idles at 0% CPU when not in use.

Maybe financially MS is successful but at the cost of flagship product becoming adware and people fleeing slowly away

Stock price going up is not the success criterion for a business. Making money is. And Microsoft's decisions are undermining their ability to make money in the future, which makes them bad decisions even if the stock price has gone up or if they make more money in the short term.

In a bubble, everyone looks like they’re doing well. Don’t confuse that with an actual strategy.

> The DOM is very ill-suited for most UI. Too complex and lots of missing features

Can you expand on this, because I'm not seeing it myself. The DOM, html+css is very flexible. It easily encompasses most UI. Most UI is some kind of data display, so lists, trees, tables, forms.

The need for JS might be what you're complaining about. I think we might be stuck with it as a UI control language forever.

The end state of genAI could as well be a few billionaires being their enterprise and everybody else being unemployed or working at the factory. Robots are not there yet (far from it) and someone needs to build and maintain the thing as well as food for everyone. High unemployment could drive salaries down and make lots of thing unavailable to the common people while making humans cheaper than automation for boring manual work.

That's an extreme scenario but today's politicians are not very keen into redistribution of wealth or prevention of excessive accumulation of economic power leading to exceeding the power of the state itself. I see nothing preventing that scenario from happening.

Eh, WinForms did a lot to make Win32 UI accessible and usable -- especially layout and easy customization -- but I have to differ on the cross-language story. It was great, IF you were making primarily a C# program that happened to use some C/C++ components.

From the native code side, it was not so great. The .NET 2.0 CLR had very poor support for hosting from the native side and really wanted you to make a program that was .NET first, it didn't work well if you wanted something like primarily a C++ program that hosted a C# UI in the same process. Reverse P/Invoke via native exports wasn't exposed, so creating DLLs for consumption by non-.NET programs was difficult. Mixed mode debugging was and still is painful, with the debugger being glacially slow at some operations like OutputDebugString() processing and blocking some native features like data breakpoints, and the CLR eating access violation exceptions from native code so they couldn't be debugged properly. Build-mode wise, we had to ban C++/CLI assemblies depending on C# assemblies because the C# project system didn't handle incremental builds properly and forced the dependent C++ assembly to rebuild all the time.

These issues still largely exist and are an issue with WPF. It's a great UI framework, but it's unusable unless your front end is primarily a C# program.

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.

> Stock price going up is not the success criterion for a business. Making money is.

Microsoft’s net income is up roughly 5.4x from ~$22B in 2014 to $119B today. Profit margin also expanded, from ~25% net margins in 2014 to over 36% today.

If the market agreed, the stock wouldn’t go up.

But I compared it to sp500. Even QQQ only 6x’d in that timeframe.

Which bubble are you talking about? Even if you remove everything after January 1 2020, it’s still up 4x since nadella took over. And that follows a decade of stagnation under Balmer.

What numbers do you know of that show that Microsoft hasn’t been successful since nadella took charge?

Complain all you want about the products, but the stock under nadella has been a success.

The DOM(and CSS) is primarily built for documents and forms, even with the latest addition like Flexbox or Grid layouts. It is closer to typesetting tools like troff, latex, texinfo than any UI engines you can think of. And some that are not needed, like the difference between <i>, <a>, <span>, <strong>,...

Also with most GUI frameworks, there's some difference between widgets like label, button, menu, checkbox,... and containers that does layout management. And there are not a lot of elements in both sets. This is the reason why React Native has a very sparse components library. With simpler implementation, you have a simpler rendering path, and the developer have less elements to deal with.

Also some have ready-made implementation of really useful widgets, like tree, grids, tables, lists, and other dynamic things. You can find libraries for those on the web, but the web implementation of scrollable container is janky.

I don't know about "most UI" but it's sure as shit ill-suited for CAD (what I work on).

> High unemployment could drive salaries down and make lots of thing unavailable to the common people while making humans cheaper than automation for boring manual work.

‘I wanted a machine to do the dishes for me so I could concentrate on my art, and what I got was a machine to do the art so now I’m the one doing the dishes’

The French will lead the way.

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.

In which case you get canvas, WebXR, etc.

The GUI system for the NeXT was based on the Display PostScript system which in turn was based for the PostScript system designed for rendering to printers. Quartz in MacOS X is a further evolution of that.

Inside HTML 5 you can find facilities for rendering documents and you can find facilities for rendering applications, including those forms. There is not a clear line between one and the other.

But you already have a machine that can do the dishes. Like doing the laundry, people forget the machines they already have doing 90% of the work. Soon enough artists will forget that computers can do 90% of their work too.

The French are on their way to put a far-right government in power next year, don't count on them.

I imagine that the rabble will need to eat only a few before the rest catch on.

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...

PostScript was for rendering graphics to a printer with a good emphasis on texts. Most of HTML is about marking up and styling interactive documents. There’s no clear line between the two, but an API for applications UI has different goals than one for document typesetting (even interactive one).

HTML have a lot of tools for devex, but if you’re going for a good codebase and simple implementation for a desktop application, QT is way easier.

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.