Live data from Hacker News

Windows native app development is a mess

domenic.me

401–410 of 481 posts

Re: Windows native app development is a mess

#401
post #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 st…

A good rule of thumb for programming languages is to check what the general recommendation is on HN and do the opposite.

Using win32 from Rust is nonsensical. This is the kind of use-one-tool-for-any-job Visual Basic 6 programmers used to have, except VB6 would have actually been much better than Rust at Windows programming.

Re: Windows native app development is a mess

#402

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…

WPF and Winforms may be stable, but they're not going to work well on a modern machine with a HiDpi monitor. Same with Win32 controls.

My take: Use Win32 for opening windows and interfacing with the OS. Use a different toolkit for actually drawing inside the windows.

Ideally a toolkit that can paint in sync with window open and resize, otherwise you'll get Electron-style window flickering. And something that supports multiple windows in a lightweight way, since you're going to want popups, menus etc. to extend outside parent window bounds

Re: Windows native app development is a mess

#403

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…

I made an app using Win32 in Golang. It controls my monitors' brightness and "true-tones" them to match the sun cycle via DDC/CI. It has autostart, global hotkeys, persistent settings, sits in the tray, silent auto updates etc.

The hard parts were seeded by Claude Code. Happily maintaining and modifying it for close to 3 months now. Just a data point, especially about not needing C++.

Re: Windows native app development is a mess

#404
post #268

Earlier quoted context omitted.

The only good thing to say about that is it removes the stupidity of using Electron (or the Microsoft Edge equivalent) for built-in Windows apps and the Start Menu. SMH.

The start menu never was electron. It's react native desktop. So, nodejs creating and updating native (well, winui 3) controls.

Heh, nodejs uses V8 which shares legacy with WebKit's JavaScript core, itself being forked from KDE's KJS. Fun to think that eventually, some KDE code spiritually made its way to the windows start menu

Re: Windows native app development is a mess

#405

Earlier quoted context omitted.

Using Win32 to write a UI in Windows is like pulling teeth. There are bindings for Rust but even still it's a nightmare. MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell. I think it's fair to say that the entire stor…

The sane alternative is macOS because there is one thing that Windows lacks; a community. Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software. When I look at the apps on Windows, all I see are abandoned projects and MVPs with a borderline malware financial structure.

Really?

I've been a fulltime Linux user for years but there are tons of excellent Windows-only apps.

Here are some that I miss: Directory Opus, ShareX, Wiztree, Everything, AltDrag, AutoHotkey, Paint.NET, irfanview, SumatraPDF. I'd add Keepass2 as well but fortunately KeepassXC is a thing.

Those are all feature-filled (in the bloat-free good way) and they've all been around for over a decade (from memory). Most are free and open source to boot.

Re: Windows native app development is a mess

#406

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.

I worked on Windows programs similar to WinAmp, which had custom drawing, skins with custom shapes, etc. Usually written directly in WinAPI, VCL (C++ Builder, not Delphi) or a combination.

It was a matter of having access to the right (although limited) resources such as Petzold’s book, Codeproject and experimentation. There was no big rush, no start-up hustler mentality and most importantly hardware resources mattered a lot and it was a point of pride to create efficient software.

The development culture of present time is the opposite of that: developers are drowning in documentation, the default solution is technically inferior and the hustler mentality’s dominating.

Re: Windows native app development is a mess

#407

I just use JUCE. It solves all the problems I need solved on Windows and doesn’t lock me into anything. More and more, if its not cross platform C++, it just doesn’t make any sense to invest in it. This is getting more relevant as the years go by, alas.

Given OS windows shares, if you are writing desktop, cross platform makes no sense for most apps.

.. except for where it does make sense, for example, you have applications that you want to deliver to MacOS, Linux and Windows users. Windows is less and less relevant these days - especially when one takes the bull by the horns and deliver cross-platform apps on purpose.

Re: Windows native app development is a mess

#408

Earlier quoted context omitted.

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? Unironically the answer is yes. I've been watching this for at least 15 years. I think one inflection point is when everybody who was coming up became accustomed to GC languages. Within a decade of that trend starting, nobody could reason about memory anymore. With the AI boom we're going through another inflection point. When coding is synonymous with using a…

The web and web apps as pushed by Google and others was another nail in the coffin of efficient software.

From Android to whatever web framework they’re peddling as development solutions, these are not designed for efficiency, but for time-to-market and consumption by front-end developers.

Re: Windows native app development is a mess

#409
post #251
post #144

Again, unless you have existing Windows 8/10 applications that were written against WinRT, UAP or UWP[0], that make use of WinUI 2.0, forget about touching anything related to WinUI 3.0 or WinAppSDK, stay away from the marketing. Exception being the few APIs that have been introduced in Win32 that instead of COM, actually depend on WinRT like the new MIDI 2.0 or Windows ML. Keep using Win32, MFC (yes it is in a bette…

For non-Windows devs (from ChatGPT): - Win32: The original Windows API (since the 90s). Still widely used. - MFC: Old C++ wrapper around Win32. Ancient, but still maintained. - WPF: .NET desktop UI framework (XAML-based). Still very relevant. - WinForms: Simpler .NET UI toolkit. Old but stable. - WinRT: A newer API layer meant to replace parts of Win32. - UWP: Microsoft’s attempt at unified apps (desktop + tablet + p…

Huh? Downvotes for providing explanations of the acronyms/tech...?

Re: Windows native app development is a mess

#410

Earlier quoted context omitted.

> "(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…

WPF and Winforms may be stable, but they're not going to work well on a modern machine with a HiDpi monitor. Same with Win32 controls. My take: Use Win32 for opening windows and interfacing with the OS. Use a different toolkit for actually drawing inside the windows. Ideally a toolkit that can paint in sync with window open and resize, otherwise you'll get Electron-style window flickering. And something that supports…

WPF scales and works perfectly with HiDPI displays, and (from what I've read) WinForms support for HiDPI has improved in recent years.
Post reply on HN