Windows native app development is a mess • Hacker News Board

Re: Windows native app development is a mess

#351

Post by ranger_danger » Mon, Mar 23, 2026, 1:40 AM UTC

Joe_Cool wrote: post #342

Onavo wrote: post #331

Earlier quoted context omitted.

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…

It works, and fast, but it is not portable. I would argue something like Qt is much more viable in $current_year for cross-platform development. Or if you're really dead-set on actual native components, then I guess wxWidgets works too.

Re: Windows native app development is a mess

#352

Post by naizarak » Mon, Mar 23, 2026, 1:41 AM UTC

For anybody interested in the use-case underlying this article, mainly disabling peripheral displays in a multi-monitor setup, this is already built into Windows via the Win+P hotkey. It's also possible to turn off all displays by reassigning the functions of the computer's physical power/sleep buttons in Control Panel -> Power Options.

Re: Windows native app development is a mess

#353

Post by ranger_danger » Mon, Mar 23, 2026, 1:43 AM UTC

lylejantzi3rd wrote: post #82

dgxyz wrote: post #75

Earlier quoted context omitted.

After bouncing around GUI toolkits (from win32 to SwiftUI) and web for 30 years I have simply run out of fucks. They all suck. Each in their own unique way. Apple aren't worth singling out - they are just their own special isolated variant of it.

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

I have no complaints using Qt for cross-platform development, it has been paying my bills for the last 15+ years.

Re: Windows native app development is a mess

#354

Post by dlopes7 » Mon, Mar 23, 2026, 1:43 AM UTC

naizarak wrote: post #352

For anybody interested in the use-case underlying this article, mainly disabling peripheral displays in a multi-monitor setup, this is already built into Windows via the Win+P hotkey. It's also possible to turn off all displays by reassigning the functions of the computer's physical power/sleep buttons in Control Panel -> Power Options.

This is not the same at all, you are pretty much turning the screen off with that

Re: Windows native app development is a mess

#355

Post by gzread » Mon, Mar 23, 2026, 1:43 AM UTC

sys_64738 wrote: post #122

cv5005 wrote: 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…

I've not done MFC Win32 programming since 1999 but if I recall those programs don't execute the main() function. They instantiate the Win32 class for your app or something like that. I can't remember any details anymore.

They don't use main because they use WinMain, which is the entry point for Windows apps that don't run in a console window.

WinMain should create an instance of the app class and call Run.

"You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 which feels pretty unfair

Re: Windows native app development is a mess

#356

Post by badsectoracula » Mon, Mar 23, 2026, 1:45 AM UTC

odkeidjwidj wrote: post #97

domenicd wrote: post #53

Earlier quoted context omitted.

Ahah, I knew I missed one! I originally had ATL in there, but my proofreading squad (Claude and ChatGPT) told me that ATL was a more niche thing for COM, and looking at the Wikipedia article I was convinced they were right. But WTL was what I was thinking of---the step between the MFC and .NET that I forgot.

> but my proofreading squad (Claude and ChatGPT) told me With all due respect (seriously): fuck off man This is why you don’t use these stupid fucking tools for this

> This is why...

...but they were correct. The GP just didn't remember the proper name and asked about a different thing.

Re: Windows native app development is a mess

#357

Post by gzread » Mon, Mar 23, 2026, 1:45 AM UTC

mkl wrote: post #340

localuser13 wrote: post #258

Earlier quoted context omitted.

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.

That survey was power users only: https://www.androidauthority.com/dark-mode-poll-results-1090... I would be astounded if a majority of general Android users used dark mode, as light mode is the default on most phones (all, IME).

Mine switches between light and dark depending on the time of day. It was the default behavior.

Re: Windows native app development is a mess

#358

Post by PlunderBunny » Mon, Mar 23, 2026, 1:51 AM UTC

NetMageSCW wrote: post #182

lylejantzi3rd wrote: post #82

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 recall there used to be a problem if you edited a (win)form in Visual Studio on a computer that didn't have the DPI set to 100% - did they fix that?

The work around was 'simply' to switch to 100% DPI scaling before opening Visual Studio. On my macBook Pro built-in monitor, this was not cool.

Re: Windows native app development is a mess

#359

Post by naizarak » Mon, Mar 23, 2026, 1:52 AM UTC

dlopes7 wrote: post #354

naizarak wrote: post #352

For anybody interested in the use-case underlying this article, mainly disabling peripheral displays in a multi-monitor setup, this is already built into Windows via the Win+P hotkey. It's also possible to turn off all displays by reassigning the functions of the computer's physical power/sleep buttons in Control Panel -> Power Options.

This is not the same at all, you are pretty much turning the screen off with that

Isn't that the point? What's the benefit of blacking-out a display instead of putting it in no-signal standby?

Re: Windows native app development is a mess

#360

Post by badsectoracula » Mon, Mar 23, 2026, 1:56 AM UTC

magicalhippo wrote: post #333

badsectoracula wrote: post #321

Earlier quoted context omitted.

> Win32 makes it reasonably easy to skin things Actually it doesn't. Win32 skinning is either making a control completely from scratch or hacking into undocumented aspects of the native controls - i.e. what WindowBlinds does. AFAIK modern Delphi has some component that basically follows the WindowBlinds approach.

> Win32 skinning is either making a control completely from scratch In almost all cases you just need to handle the drawing yourself, and you get fairly broad access through the API to do so through the various non-client and client window messages. Now, Windows has gained some newfangled components over the years with more or less integration, I'm thinking basic Win32 controls.

What all cases? Windows (basic Win32 at that) provides a lot of controls like buttons, checkboxes, inputboxes, scrollbars, radiobuttons, comboboxes, listboxes, etc which do all their drawing themselves and you do not have any way to fully skin them (without hooking into undocumented stuff). Some controls allow for custom drawn elements but pretty much always that is just for the elements themselves, not the entire control.