Live data from Hacker News

Windows native app development is a mess

domenic.me

271–280 of 481 posts

Re: Windows native app development is a mess

#271

Earlier quoted context omitted.

Only a very small minority of users actually care about dark mode. It is not a general expectation for software, as loud as those users may be on forums like this one.

And how do you know this? I decided to check myself, looked for dark mode statistics on android, and: >Dark mode is used by 81.9% of 2,500 Android users on their phones, in apps, and in other situations. 9.9% alternate between the light and dark So it's the other way around. Only a very small minority of users actually care about light mode.

I think android is a big difference here. What about excel or Google sheets? Word?

If you're building win32 you're not targeting android.

Re: Windows native app development is a mess

#272
It is not. Not to that extent at least.

I am developing Sciter[1] engine that works on all desktops: Windows, MacOS, Linux (3 distinct backends: pure X11, pure Wayland and GTK4).

Among all those, Windows API is still the most consistent and stable.

Whole of Windows functionality can still be accessed by plain C. For some things (COM) is better to use C++ but C works too.

Just in case: I am in this business for 20+ years.

[1] sciter.com

Re: Windows native app development is a mess

#273
post #11

I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I find it a breeze to write native gui programs in pure win32 and c++. Recently had to add a new feature to and old program that was last updated in the XP era and two things to note: 1. The program did not need to be updated to run on Vista, 7, 10 and 11, shit…

and it would work on linux with wine lol.

Re: Windows native app development is a mess

#274

> However, for no reason I can understand, Microsoft has decided that even the latest versions of Windows 11 only get .NET 4.8.1 preinstalled. .NET has new releases every year, supported for 2 or 3 years. That’s not really compatible with Windows release cycles. Also, if Windows 11 25H2 shipped .NET 8, and now Windows 11 26H2 would ship .NET 10, apps which depend on version 8 might break. Easier to just think of .NET…

.Net has always been hugely backwards compatible and breaking e.g. .Net 8 apps which will run out of support in November 2026. How is constantly needing to update .Net any different from constantly needing to update any other part of Windows? Ideally they would just install newer .Net releases side by side and uninstall .Net releases as they drop out of support.

Microsoft promises things included with Windows will be supported ~forever. Adding modern .NET into the mix would break this promise and add more churn.

Automatically uninstalling .NET runtimes would break apps, and Microsoft will be to blame, not app vendors who failed to upgrade to the latest .NET. An app built for .NET 8 can run on .NET 10, assuming no backwards-incompatible changes in the runtime and system libraries, but this behavior is opt-in.

Re: Windows native app development is a mess

#275

The author is right, it's really such a mess. The lessons I've learnt building and shipping a few a Windows apps at scale are basically: (1) Learn Win32 and use those ancient APIs if possible, they're extraordinarily stable and you'll probably need to reach for them anyway. They're not that scary. (2) Don't use any Microsoft-owned UI toolkit, you'll get burnt. Literally anything is better. Ideally choose a toolkit th…

> "(2) Don't use any Microsoft-owned UI toolkit, you'll get burnt" This is 100% true for all of their techs produced within the past ~20 years, but WPF and Winforms are extremely stable with no real issues. It's so weird too because most of everything they've done in the past 20 years has basically just been incomplete remixes of WPF. If they just stuck with WPF and extended it onward, something like a UI toolkit equ…

the should just have updated wpf with their newer widgets and just continue to improve it and even make it cross platform. (basically what avalonia is doing)

Re: Windows native app development is a mess

#276

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…

IDK man, I wonder how TF did the creators of Winamp do it? Were they so much smarter than the programers of today? And Winamp 2.95 still works on WIndows 11 today. IIRC Borland Delphi was the most popular tool back then for making Win32 apps since it was so easy to use.

Were they so much smarter than the programers of today?

The average programmer back then was probably far more knowledgeable of the low-level details.

Re: Windows native app development is a mess

#277

Earlier quoted context omitted.

But, why? It's been 30 years. You'd think somebody would have figured out how to make a decent GUI toolkit or framework.

Have you tried WinForms? It isn’t the latest hotness so Microsoft has to be dragged kicking and screaming to support it in current VS, but they were forced to do so because corporate developers still have some clout.

I still think that WPF was the peak desktop UI framework. Extremely powerful with lots of small composable primitives, can easily do declarative but drop into more traditional event-driven imperative style where it makes sense.

Re: Windows native app development is a mess

#278

Earlier quoted context omitted.

A question - Which portion of Microsoft, the multi-headed beast develops pure-native apps now ? Even the Windows 11 Settings app is Javascript. The multi-headed beast has been assimilated by web-tech. They can't code GUI C++ no more - except their compiler/graphics team. And even the latter are dying.

There are like three settings pages that use JavaScript and React Native, the vast majority of Settings is C++ and XAML/WinUI2

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

Re: Windows native app development is a mess

#279

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…

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 less information in the name of "modernity". There's a lot of specialized niche software for various industries, often very expensive too, which looks like it came out in the early 90s. As long as it works well, users won't complain.

Re: Windows native app development is a mess

#280

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…

Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it is to be considered in certain situations.

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

Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are still some reasons to do so, of course, but Win32 isn't one of them -- one can use it from a memory safe language just fine, e.g. https://github.com/microsoft/windows-rs

Post reply on HN