Things like:

- If you can't respond to a UI event wait until you can

- Menus should be tree structures

- Pressing alt should underline the hotkeys you need to access anything clickable

As well as just basic responsiveness or predictability. A 2000 era windows application may not have been pretty, and may well have several different styles all imitated from office, but at least I knew what everything did and when it was slow at least it did what I expected.

This meant I could start the computer, log in, potentially start and use several applications and only then turn on the screen. Nowadays that has no chance of working because even to log in I need to press enter or click some button (which one depends on how I logged in previously, maybe) before I can even start typing and doing so eats a random amount of keystrokes while the damn log in screen loads to do its one damn job.

As someone who saw what impact WPF had on average users running average hardware in the late 2000s to early 2010s, I disagree.

In 2011, my brother was in seminary, using an average Windows Vista-era laptop that he had been given in 2008. When he was home for Christmas in 2011, we were talking about his laptop, and he told me that the Logos Bible software ran sluggishly on that laptop. He said something about how, for reasons unknown to him, the current version of Logos required advanced graphics capabilities (I forget exactly how he phrased it, but he had learned that the slowness had something to do with graphics). Bear in mind, this is software that basically just displays text, presumably with some editing for adding notes and such. At the time, I just bought him another laptop.

A few years later, I happened to read that Logos version 4 was built on WPF. Then, remembering my brother, I found this Logos forum thread:

https://community.logos.com/discussion/6200

This shows that Logos users were discussing the performance of Logos on machines with different graphics hardware. For a program that was all about displaying and editing text, it shouldn't have mattered. WPF had made a bet on then-advanced graphics hardware for reasonable performance, and that was bad for these users. And that's just the one example I know about.

Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.

How did MS actually implemented it though? After a few messages the chat is blocked because MS did not choose to walk the extra mile and maybe compact the context so that their product can be actually usable.

Of course OpenAI, Perplexity and others later implemented that properly and its integral part of modern AI chat and I actually ditched Google for the most part. Had Microsoft done it, they might have had a shot in replacing Google and maybe becoming the AI Chat provider. But no, Microsoft can't have a well thought UI to provide a delightful UX.

IMHO it's a culture thing. Lack of cohesion is a result of it, I used to be annoyed by Apple that doesn't allow to ship its own UI libraries together with the app so to support old versions etc. but Apple had it right, thanks to the limitations UI is coherent.

1) They abandoned their mobile phone, tablet, and wearable strategy. So, today if you develop a native Windows application, it will only work on desktops and laptops. That is it. It is not attractive for a developer to learn a whole new UI framework just to target a single form factor. And I don't know if there is any solution for this at this point, they shouldn't have completely abandoned those markets.

2) They did not back 1 UI framework for a long time (I mean 10 years+), instead they did significant changes to their UI framework strategy every 3-4 years. It takes a huge time for developers to trust, learn and develop complex and polished apps in a UI framework. Also it takes a long time for a UI framework to become mature. If you change your UI strategy every few years, you will never have complex and polished apps written with it.

To be honest I am not sure if Windows will ever be able to recover in the long term and keep its market share. The only reason it seems to be alive is because enterprise runs on Windows and it is hard to change that.

I feel like an Apple + Google dominance will be more likely in the long term for desktop operating systems. I am not sure if Google will be able to avoid the first mistake I wrote above but they are working on bringing Android to desktop. It is a good idea but it requires at least 10 years of supporting and polishing it despite not getting much traction. But if Google persists, we might be all using MacOS and Android on desktop 20 years from now.

Microsoft has bought into ‘make a web app’ since 1988, they introduced AJAX, they got flexbox and grid into CSS and numerous HTML 5 features to support application UIs. They ‘frikin bought npm!. I use Windows every day but I almost exclusively develop cross-platform systems based on the WWW, Java, Python, etc. Whenever I have developed with .NET it has been for a cross-platform front-end like Silverlight or Unity/itch.io.

I can’t say I have a desire to make a native Windows GUI app when I could make a web app: like if it worth doing from my computer isn’t it worth doing it on my iPad from anywhere with Tailscale? For all the complaints about modern JavaScript it gives you the pieces to make a very pleasant world in terms of DX and UX and you certainly don’t need to ship an Electron runtime for many applications.

They had something reasonably good in WinRT. They should have stuck to that. But Nadella came in, said Azure Cloud is the future and abandoned the Windows platform.

It's 2026. We're running 8+ cores and 32gb ram as standard. We can run super realistic video games at high frame-rates.

Yet on the same machine, resizing a window with rectangles in it is laggy on every platform except macOS (where there's a chance it's not laggy).

Fortunately Rails was taking off at that point so it was fairly easy to change horses and just ignore it.

I never understood.NET's purpose. What problem it exactly went out to solve? Did Microsoft want developers to be able to run their applications everywhere too? Absolutely not.

Sidenote - MFC is the ugliest thing you'll see. Yet they didn't mention another piece of work called ATL. Active Template Library.

WinForms were really decent and that was enough. Keep Win32 API and a managed wrapper around it as WinForms and that would have been more than enough.

.

https://x.com/stevesi/status/2036921223150440542

That's fine, except no platform answers this.

Obviously Linux doesn't, but the Mac doesn't either. Apple of course has it's recommendation, but most developers do not take Apple's recommended path because of course, it's Apple-only, most developers make cross-platform apps these days.

Even if Microsoft decreed the one-and-one Windows development path, most developers are not taking that path.

It used to be the case that Mac developers used Apple tools, Windows developers used Microsoft tools, but those days are gone. Developers want to use Electron, or Qt, or some other system to support multiple platforms in one codebase.

Microsoft has less to do with this than the article makes out. I'm a desktop developer. I don't care what Microsoft recommends, or what Apple recommends, because neither work in the real world where supporting only their platform just isn't realistic.

Invested in it, shipped it, seen it solve the cross-platform problem beautifully.

Can just write C++, and see it running everywhere.

The JUCE GUI capabilities are more than adequate for many, many things.

There are other platform-scaffolded cross-platform frameworks. JUCE is cromulantly FNORD.

(This isn't even a joke. Assuming you're not going Electron.)

Part of the reason here is that it's their main business. They can't afford letting it languish and/or changing direction every 6 months.

I know it’s not a popular opinion, and I am sure there were reasons Microsoft abandoned it, but that was a brief few years when I actually enjoyed building GUIs on Windows.

- windows forms in .net

- flutter

All the rest always presents itself with a sheer aura of "It was a great idea but we couldn't finish it".

Without ever discussing with anyone from MS about it, I think they stopped improving/working on this because of electron.

Any web developer can build a good enough website and a good enough desktop app with electron.

A few years ago, I wanted to prototype something quick and I wrote it in Windows Forms over C# (all code, no visual editor).

Fast forward to now, and KDE Plasma is state of the art Linux desktop that I've been daily driving for years. It's also built on Qt.

Most embarrassing failure in the company’s history that far.

Microsoft has been developer first, then cloud first, now AI first. It has never been design first. And when something does work, the pattern is always the same: force it everywhere. Metro was genuinely good on mobile, then they pushed it onto desktop where it didn't fit. Now Fluent UI is repeating the cycle.

Fluent UI is on its third major rewrite (Fabric, then Fluent UI React v8, then v9). Each one brought breaking changes. v9 appeared around the same time Microsoft released their new Teams client, and it shipped with performance and accessibility issues that are still being worked through. Signs already point to the next throwaway Fluent UI version. In practice, Fluent seems to be first-party only. It's 'open source' in the sense that you can look but don't touch. In SharePoint alone, the same UI elements look different across pages, lists, document libraries, and settings panels.

The irony is that the web platform itself has caught up. You can build a fully themed, accessible component library in plain HTML and CSS today. No framework dependency, no version lock-in. I did exactly that with hTWOo (https://htwoo.io/), an open-source alternative that matches the Fluent design language without any of the React coupling.

The real problem isn't that Microsoft can't pick a GUI strategy. It's that they keep rebuilding from scratch instead of creating a design system flexible enough to sustain across platforms and product generations. The web platform already provides the primitives. You just have to commit to them.

Er… The author perhaps never used it? WPF was the worst framework I ever used. It was unbearably verbose, brutally unforgiving, used 2-way bindings that created updating nightmares, ans not the least it was incredibly slow.

WinForms was not the best for sure, but at least you can get stuff done. It was for a long time the right answer to the question the author asked. .Net + WinForms worked well.

When WPF shipped was when the shit hit the fan.

Thankfully I have been mostly insulated from it by sticking to Qt and C++ for the last 25 years.

Xaml and styling and all sorts to try and compete.

Trouble is, it made desktop development harder, and it didn't win against the web. It left the simple and safe formula of standard and common controls for a designer's playground, but the designers preferred the web. And if you make something for the web, you can package it in Electron and get cross platform cheaply.

Microsoft keeps footgunning things so hard I think even enterprise might be reluctant to go with them moving forward [0]. I don’t have Netcraft numbers in front of me but I doubt things have notably improved even if they do have a strategy shift to enterprise which includes crapping all over Windows for no good reason.

I’m personally glad FOSS is going strong but that’s a complete aside.

[0] We got burned by Azure as I’m sure many other enterprises have, and they did exactly nothing to remedy/compensate the situation, SLAs be damned. At this point our strategy is to move off of reliance on any Microsoft/windows tech. We moved off of ActiveDirectory not too long ago. Bing/Edge/etc honestly who cares.

It took them more than 2 decades to finally support pure native binaries (via NativeAOT). And it's fantastic for servers on Linux.

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

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.

Microsoft developed VS Code and Teams in Electron. That says a lot about how they see the future.

https://blog.hiler.eu/win32-the-only-stable-abi/

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.

Ostensibly, grading by impact is fine: they want people who make a positive difference. In reality, it means that creating is better than finishing. Now add in the cold realities that at any given time in Microsoft, some groups are on the up and some on the down. What's a great way for a group to regain some status? Launch something. Jazz it up for the Build or Ignite crowd. Get some dev evangelist to talk about it. Then get on the job board and slide over to another team ASAP. You're a High Impact person. Who wouldn't be happy to have you?

Windows and Mac in the 90s had very consistent GUIs with such consistency in things like keyboard shortcuts that apps could easily be learned. The term “intuitive” was king in the realm of UI design.

Then the web hit and all that died.

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

Everything that came later was basically a struggle to make something that Electron actually delivered.

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.

Windows Native App Development Is a Mess

https://news.ycombinator.com/item?id=47475938

1. Drop all its GUI stacks apart from legacy Win32

2. Port KDE Plasma to Windows (with aliased bindings to support traditional explorer.exe calls so as to not break user apps)

That's it. There really aren't many significant apps that use the rest of Microsoft's stack apart from Win32 that won't recover from this, and Microsoft itself will just see a massive drop in its own costs with a massive rise in user satisfaction.

https://imgur.com/a/dWp5Ohj

Did they even try to make it look like the new context menus?

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.

It's almost like the major desktop platform vendors have all given up on supporting high-quality native desktop applications.

Microslop should have been dismantled decades ago, it's now too late, we need a paradigm shift so that Microsoft no longer affects our society

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.

I wonder if we attended the same conference session!

That AI image at the end was more amusing than informative. Almost lost it at "Win15" and "Chrondum + frade.js".

The cleanest design I came up with works like this:

1. At Layer_1 OS provides panes or windows to which apps can render whatever graphics using OS gpu lib (think Raylib, but maybe a bit simpler). This is good for apps that want performance, games, text editors, things like that - so this is maximum control.

2. Next Layer_2 would be based on the browser engine (which, to some degree, would have to be developer - not a full browser, but just enough to render more or less modern html/css with a DOM-aware JS engine). Then provide some XML schema that would automatically translate into HTML/CSS to render various UI-widgets (defined by XML/HTML elements). This would eventually suggest a JavaScript UI framework on top, but no a requirement. This layer is flexible enough that it uses widgets defined by the system, but allows custom CSS and JavaScript.

3. Layer_3, or more like Layer_2.5 would basically allow custom HTML/CSS without relying on system widgets and XML schema.

Obviously you can mix all three layers into one GUI too. Finally layers (2) and (3) would require some client/server architecture, but instead of shipping it like a webapp, I'd probably provide some JavaScript API to talk to the backend (which in this case is accessible via a socket of some sorts). Apps themselves could still be single binaries that include html/css/js assets which are provided at launch time to the system UI renderer, which then uses them to render the UI via a webview in said pane or window.

I think it's pretty slick and it only gets complicated gradually, but it also requires solid OS plumbing and machinery to make this process smooth. None of the modern systems are capable of it in the way I described it, so people end up shipping nodejs/react apps with webview inside gigabyte-binaries.

Could have been Ballmer getting a quick snack in before anger-presentation.

What's still missing is deeper integration with native OS concepts and programming languages other than JS. Frameworks like Electron are a step in that direction but they come with notable drawbacks. Applications often struggle with things that should feel natural like managing multiple OS-level windows.

Another PITA: Electron apps repeatedly bundle large portions of Chromium, leading to unnecessary overhead. Those duplicated modules lead to bloated RAM usage: every app has its own Chromium copy and OS must keep all that zoo in RAM without a possibility of reusing the otherwise shareable parts.

It's all win32 underneath except for UWP, which is now deprecated.

so the answer is win32, raw winproc.

The issue is they haven't made a new GUI API (only frameworks) since win32.

The layers of outdated and conflicting documentation, fragmented logins, the naming (365, live, .net [both naming everything that and the .net core naming labyrinth], copilot), Teams never made sense, Windows had levels and levels of settings (win10 preferences all the way back to dialogs predating the mammoth).

MS was, is and always be a blight upon this earth.

To be brutally honest, if you were a serious Windows developer in those days (and you were even the sort who'd have sat through a conference session on the topic); there is absolutely no way in hell you'd not understand the difference between OLE, COM, and ActiveX. Conflating these things as some sort of confusing mess either shows a lack of actual experience, a lack of competency, or a desire to falsely make things seem more confusing than they were to add some meat to an article.

This article dances with some good points, but opening up with this sort of hyperbole (and then ending it with an unabashed AI slop image filled with brand new hallucinated characters of the alphabet) just totally tanks the author's reputation.

It is a fantastic book, I learned everything I know on Win32 from it. Wrote real time scientific software in windows for ~10y! We did it all, external hardware control, custom UIs, etc. Thanks Ryan Geiss for your timing info.

Right about VC6 was the sweet spot imo, C/C++ with lightning fast UI for docs and more. Tools got out of the way. Once other languages got involved (C#?) the docs got out of control and harder to use, and the UI started to get a little overloaded.

The snappiness of those old windows systems was pretty great.

>> Jon Udell found a slide from Microsoft labelled “How Do I Pick Between Windows Forms and Avalon?” and asks, “Why do I have to pick between Windows Forms and Avalon?” A good question, and one to which he finds no great answer.

And:

>> Which means, suddenly, Microsoft’s API doesn’t matter so much. Web applications don’t require Windows.

What he didn't see is, however, Azure would become the money printer for Microsoft and made all these no longer matter.

[0]: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

Moreover, there isn’t much in the way of alternatives. Everyone likes to hate on MS —for decades this has happened and nothing came of it.

Also, the AI smell in this article is just too much.

Jobs, Musk, Edison, whoever.

Someone who will enforce their design decisions, get stuff done. And take the hit when they are wrong.

From a user's perspective, I don't really see where the problem is. All my apps look like Windows apps to me, and I also think that includes apps that do their own thing and look their own way. For as long as Windows has been around we've had apps that just don't follow the rules, from RealPlayer to WinZip to iTunes to Spotify.

This idea that all applications must be consistent with each other on one platform is generally a good idea but the downside of not having it that way is not very tangible to most users.

E.g., Steam looks different than every other Windows app. Same with Spotify and Slack and Discord. How does that negatively impact users? Well, not really at all. The consistency is within those apps themselves. I'm comfortable with Steam because I've been using it for 20 years and it's evolved on its own terms.

I could see it being an accessibility problem, but can't figure out any other potential downside.

I also don't think any other platforms have this figured out. See the window corners in macOS Tahoe. Remember how Mac Catalyst apps first looked when that came out? They didn't follow OS conventions at all. Remember when Final Cut Pro 6 didn't look anything like a Mac app? Or GarageBand etc. and their skeuomorphic looks? Linux is no better with a mix of desktop environments, Wayland versus Xorg, etc. Then we look at mobile apps and it's one of the least consistent environments imaginable: you've got a mix of native and frameworks like React Native and Flutter and the rest.

> That silence is the story.

These LLMs are just awful at writing.

I’m not sure what Microsoft can possibly do when the closest thing to a collection of power users is this painfully repetitive.

Every WPF program was laggy and took ages to even start up (is everyone forgetting hard disk speeds?), partly due to it being managed code. The components didn't feel native either, and the coupling to managed code and garbage collection basically ensured all those would be perpetual issues. Yeah the programming model was beautiful and all, but you're supposedly developing to make your customers happy, not to make yourself or computer scientists happy.

You can see how terrible it would've been to base Windows's shell on WPF by looking at how much users have loved the non-Win32 windows since then.