Live data from Hacker News

Windows native app development is a mess

domenic.me

341–350 of 481 posts

Re: Windows native app development is a mess

#341

Earlier quoted context omitted.

There's a pretty simple settings window: https://github.com/domenic/display-blackout?tab=readme-ov-fi... Would that UI be hard to accomplish?

The functionality of that is not hard at all. A few checkboxes, a trackbar, and a hotkey control (there is actually a standard Win32 control for this: https://learn.microsoft.com/en-us/windows/win32/controls/hot... ), with "pushlike" checkboxes at the top to be drawn replicating the monitor layout. But that "modern" style is... disgusting and repulsive. That whole dialog is bigger than one of my monitors due to how m…

My favourite example of "Modern" style is the toggle switch, shown even in that image. I laugh a lot of the times I see one, it's the 'replacement' for the checkbox, but it's so awful at actually telegraphing it's current state in a consistent way- (the entire purpose of the control!) that it has to have a label indicating whether it's on or off. I find it so absurd that people genuinely put this stuff into their programs and have no problem with it, because apparently we are just supposed to accept this type of poorly designed component because it's more "Modern".

Re: Windows native app development is a mess

#342
post #331

Earlier quoted context omitted.

You mean conceptually or to match it? Native components are pretty much impossible to match without actually using the native framework which provides them, so you need WinUI/WPF. Win32 provides its own components which are basically Win95 style apps, and you can draw the components using some graphics APIs by yourself. The whole native development area is a mess exactly because making your own (decent) renderer is a…

But you are making false equivalence, the Win32 GUI API is decades out of date from modern UIs. I can use flutter and make a pixel perfect equivalent of the above UI in an hour, with the exact same responsiveness behavior on both windows tablets and desktop, and scales perfectly in high DPI displays. 3 hours if you want the toggle animation timing to be exactly the same. I came from the WinForms world so don't preten…

You talk like that is a bad thing. Win32 UI works, is fast, works everywhere even on ancient 640x480 server screens, safe mode and vnc in 16 colors without opengl, directx, Angle or vulkan.

Flutter is nicer to scale and maybe design but it is a massive overhead. Skia still has trouble with some drivers and causes lag or falls back to software rasterization. Hot replacement while coding is pretty neat though. It runs much better on mobile devices imho.

Re: Windows native app development is a mess

#343

Earlier quoted context omitted.

Judging from the screenshots, that doesn't produce Windows 11 style UIs, right? I.e. it contributes to the problem exploree at https://ntdotdev.wordpress.com/2023/01/01/state-of-the-windo...

Maybe I grew up with Windows so the older uis don’t phase me, but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland. The average Windows user might stumble on an aero dialog, which is arguably less jarring in win11 than og metro.

> but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland

I've been around long enough to remember MS and their fans banging on about how bad other OSs were for their inconsistent interfaces, so I feel justified in getting a little riled at the hypocrisy of how much of a mess UIs are in Windows these days.

And I don't see it getting any better - they'd rather spend the time finding new places to slip in adverts. And this is far from the fault of app developers, while they often do have something to answer for wrt consistency, because the worst culprit is MS themselves both in their apps and the OS.

I shouldn't have to click to make sure the right thing has focus for instance, particularly after switching from another virtual desktop, I should be able to see this information easily but there is no consistency in titlebars and other window chrome any more.

Re: Windows native app development is a mess

#344

I write .NET Framework 4.8 apps. And I will until .NET has an actual support lifetime. 4.8 will still be supported and receiving security updates in ten years, .NET 10 will be gone in 2. Hobby projects should not be built on a platform that is constantly changing underneath.

It doesn't really matter anymore. When .NET 10 is done, there will be .NET 12 and all your apps will run just fine on it.

.NET framework used to get new versions as well; it's just that it's not anymore. After moving on to newer versions, .NET framework feels clunky now. Also you end up missing out on a decade of new libraries.

Re: Windows native app development is a mess

#345
Small nitpick. 4.8.1 was .NET Framework, which is a totally different beast that .NET (1 through 10). .NET Framework was heavily dependent on Windows, while .NET (1 through 10) are the newer OS independent system. It's not that they've forgotten to update the system .NET, its that that product is in long term maintenance only mode and modern .NET is a totally different software.

Re: Windows native app development is a mess

#346

Earlier quoted context omitted.

but that was already developed, all new development it's going with web based at microsoft

Id be interested in a source for both this and the parent's comment. How do we know which settings pages use which tech? Have people been decompiling them?

Pretty easy to know by just looking at app install folder, or, with Visual Studio, without any need to do any decompiling.

In practice, I guess most people realize because web tech just behaves different than native.

Re: Windows native app development is a mess

#347

I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid. Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that: Enumerating the machine’s displays and their bounds A few API calls. Probably a few hundred bytes. Placing…

>> But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.

> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.*

Eh. I spent many years writing cloud/backend software on the JVM, in between stints writing desktop software. When I was first writing desktop software, it was all in C and C++, and I got used to it, but it wasn't pleasant.

When I came back to writing desktop software in C again (just a few years ago), after writing in memory-safe languages for so long (Java, Scala, Rust, Go), I found going back to C to be just so tedious and annoying. It's just incredibly unpleasant to be chasing down segfaults and data races and crap.

So I think saying it's a "crime" is hyperbole, but even for apps that don't have untrusted input, it's still much more pleasant writing in a language that doesn't let you write memory safety bugs.

(Absolutely agree with you on how it's possible to make nice, small, non-trivial Win32 apps, though I haven't done Windows app development in a couple decades. But I think a lot of people would save themselves a lot of time and headaches if they reached for .NET or something higher level.)

Re: Windows native app development is a mess

#349

Earlier quoted context omitted.

How do you make your win32 app look good to the average person?

Depends what you mean by "look good". The main function of the app being discussed here is to draw solid black rectangles on the screen. Don't forget the "average person", I'm assuming someone relying on software as a tool, doesn't care about the stuff "designers" seem to obsess over, and will actively hate if you break their workflow by doing things like adding useless padding that makes them scroll more or shows le…

[deleted]

Re: Windows native app development is a mess

#350
post #215

Earlier quoted context omitted.

Programming with GUIs?

Why wouldn't you program a GUI with a GUI if one is available? Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.

I would say having a good hot reload system gives you the benefit of wysiwyg with more readable code
Post reply on HN