Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem is that Microsoft is still pretending that UWP/WinUI isn't a complete mistake. All those issues are inherent to that technology.


The same Microsoft who said UWP was not the future only two years ago, is still continuing to rewrite applications in it?

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

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


Well, who said it? Where are they on this org chart: https://www.globalnerdy.com/wordpress/wp-content/uploads/201...


Yes, because WinUI is a clusterfuck so they need to keep using what they have.

Currently 2307 issues open, https://github.com/microsoft/microsoft-ui-xaml/issues

And this is just one repo, then you can hop into C#/WinRT, AppSDK, C++/WinRT ones as well.

Hence why they keep releasing WinUI 2.x series, although 2.6 was supposed to be the very last one before WinUI 3.0 goes stable.

However if you go to the community meetings everything is rosy and we should all be jumping into WinUI 3.0.


I came back to Windows Gui development this autumn, and we thought we'd try jumping in to WinUI3 as newer == better, right? Really hasn't worked out that way. It's literally only just hit 1.0. The prerelease versions had problems with "unpackaged" deployment (which is one of the key things we want, so we don't have to wrestle with the Windows store).

I just got an internal email saying "MS has a very convoluted process for getting a developer account just to publish apps to the Microsoft store and not even our MS rep knows the correct answer" from the person trying to set that up, so that's going well too.


Yeah, I really don't want to be on their shoes, and if we on the outside don't make our pain points clearly visible, I have the feeling that management will never change course.

On the outside it looks they have made a mess across teams, and now everyone is competing for our attention regarding Forms, WPF, WinUI 2.x on UWP (XBox, HoloLens, Windows until WinUI 3.0 catches up), WinUI 3.0 (some day), MFC (WinUI with C++/WinRT is a mess except for ATL/WRL fans with their deep IDL/COM love), MAUI, PWAs, or better yet, just wrap Blazor everywhere.

So I can't belive they are like the dog on a burning house, rather not allowed to fix the mess that Windows 8 brought into Windows development, and talk publicly how they actually think about all of this.


They've absolutely lost their roadmap, and I think they've also lost the distinction between solving a problem that Microsoft has versus a problem the users have.

And they've never quite dealt with having their platform be eaten by the web and the Apple Store / Google Play Store. See https://blogs.windows.com/windows-insider/2021/10/20/introdu...

There's also the tension between dotnet core trying to be properly cross-platform vs having it actually support the various Windows toolkits. They've historically been welded into the build system as first-class citizens, rather than optional packages, which causes trouble as soon as you do a cross-platform build. WinUI3 goes halfway to fixing that by being installable as a package, but still relies on "<UseWinUI>true".


Yes, I can clearly see that point of view.


They should just go back to pure Win32. First thing to port: Teams.


Win32/Winforms (can't really cope with DPI scaling) or WPF?

As pjlmp says, that would be an admission of failure.


Tons of politics, and not wanting to lose their face.

I lost count of how many PMs I got to see on comunity meetings since the Windows 8 days.

They also pretend that all the rewrites that keep being requested since WinRT was introduced, and rebooted on the process, aren't a big deal.

When faced with these questions they always ask for us to explain our viewpoint, as if it wasn't clear for them to start with, of course it is clear, but they cannot say it live.


Doesn't UWP/WinUI render using DirectX? What makes it so slow?


Prevailing reason for the speed of ms code:

>I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively.

https://github.com/microsoft/terminal/issues/10362


Didn't someone then implement a terminal emulator with colors, unicode support, fonts etc and it wasn't a doctoral research project?


So rendering glyphs (with textures?) is slow, vs GDI.

And I guess DirectDraw lacks a fast API to do colored text?


Just take a look at the last 25+ years of GUI development.

In all that time, as computers have got blindingly fast, the one and only constant is the guarantee GUIs continue to get get slower.


I'd like to know this too-- my music player has a few different rendering options for one on screen view, GDI has always used fewer gpu and cpu resources than direct2d and direct3d in 7 and 10 so far?


When I tried to do some Direct2D a few years ago it was a disastrous API and far slower than old GDI.

The "Disable hardware acceleration" setting, when present, still frequently makes all sorts of desktop software run faster and less buggy.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: