Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows native app development is a mess

domenic.me

Post reply on HN
Print view View original

221–230 of 481 posts

Re: Windows native app development is a mess

#221

Post by fodkodrasz »

layer8 wrote: post #169
pjmlp wrote: 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…

In that light, it is troubling that Friday’s blog post [0] announced “moving core Windows experiences to the WinUI3 framework” as a measure to improve the quality of said experiences. [0] https://blogs.windows.com/windows-insider/2026/03/20/our-com...

These steps are necessary stepping stones in getting the thing good, the question is, given Microsoft's tendency to abandon UI frameworks halfway, apart from the classical ones listed above, is if they will keep it focused until its gets as mature as those.

Re: Windows native app development is a mess

#222

Post by Pesthuf »

Thanfully, you don't need to write p/invoke stuff yourself anymore. https://github.com/microsoft/cswin32 creates methods and all related structs for you. It's also AOT compatible (if you specify it). It works for calling C and COM functions.

I mean, not like this brings Windows development anywhere close to "modern", if anything, it feels like you're moving into the opposite direction, but at least this solves the "The modern APIs don't provide the specific functionality I need" problem that plagues all of Microsoft's "nice", "modern" abstractions…

Re: Windows native app development is a mess

#223

Post by spacechild1 »

glitchc wrote: post #140
drnick1 wrote: post #138

> But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime. I disagree, the GUI layer is far from behind a safety critical component, and C++ is a battle-tested choice for everything from GUI, videos games, to industrial applications. If C++ is safe enough to control airplanes and nuclear reactors when used well, it is certainly safe enough for something as trivial a GUI. The art…

Yet we cannot consider Qt to be native app development since every app requires the Qt runtime. Native means system libraries only.

There is no Qt "runtime". Qt is just a library.

> Native means system libraries only.

Every non-trivial application will eventually use third-party non-system libraries.

I think "Native app development" has at least two meanings:

1. narrow meaning: the program uses a native UI toolkit (Win32, Cocoa)

2. broad meaning: the program targets one or more specific platforms and the UI is not not just a webview

Even with the narrow meaning, WxWidgets would qualify as "native development" (because it uses native UI toolkits under the hood), yet it is still a third-party library.

Re: Windows native app development is a mess

#224

Post by lwkl »

gzread wrote: post #212
ack_complete wrote: post #186

Earlier quoted context omitted.

The main thing that's hard going down this route is dark mode support. The Win32 USER and common controls just don't not support dark mode, but are actively hostile to it due to the amount of hardcoded light colors and backgrounds in the system. All of the system colors are light regardless of the dark/light system setting, highlights are hardcoded to light blue, disabled controls use a hardcoded color, half of the w…

First, dark mode is for people who set their screen brightness too high. Second, win32 is designed with the ability to change all the default colors and you used to be able to do this by right clicking the desktop and selecting "properties". If dark mode doesn't follow this - just another symptom of Microsoft's siloing incompetence. The team that wrote dark mode may not have been aware that this feature existed becau…

It is not. I have some issues with my eyesight and dark mode makes it easier to use a computer in some lighting conditions. So for me dark mode is an accessibility feature. And yes you could use the ugly recolor feature windows has but dark mode does the same thing and looks better most of the time cause a UI designer actually looked at it.

Re: Windows native app development is a mess

#225

Post by lstodd »

rwmj wrote: post #59

This is quite timely as we need to write a simple UI for Windows (a few buttons, status, maybe a file menu). The main constraint is it must compile to a single binary (.exe) with no dependencies such as runtimes, DLLs, languages etc. It also needs to run on some older unsupported Windows systems, probably Windows >= 7, 32 bit. My first thought was MFC. Basic, fast, well understood. But then maybe WxWindows so we can…

For such a trivial thing I'd just take imgui.

MFC, wx, Qt .. it's all overcomplex pointless bloat for this task imo.

Re: Windows native app development is a mess

#226

Post by rubymamis »

Conan_Kudo wrote: post #92
rwmj wrote: post #59

This is quite timely as we need to write a simple UI for Windows (a few buttons, status, maybe a file menu). The main constraint is it must compile to a single binary (.exe) with no dependencies such as runtimes, DLLs, languages etc. It also needs to run on some older unsupported Windows systems, probably Windows >= 7, 32 bit. My first thought was MFC. Basic, fast, well understood. But then maybe WxWindows so we can…

> Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically? You need a commercial license for that, but yes you could. But since applications are typically distributed with install bundles that put into application-local program files directories, it's not super-important as long as you only cherry-pick the Qt libraries you need.

This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.

I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.

[1] https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

Re: Windows native app development is a mess

#227

Post by userbinator »

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 borderless, titlebar-less, non-activating black windows

Creating non-functional windows is trivial. Another few hundred bytes at most.

Intercepting a global keyboard shortcut

A few dozen bytes to call SetWindowsHookEx.

Optionally running at startup

Write to the appropriate registry key. A few hundred bytes.

Storing some persistent settings

Ditto. Another few hundred bytes. You can use a .ini file too, for around the same size.

Displaying a tray icon with a few menu items

Most of this size of this will be the icon itself - a few kilobytes; the next biggest contributor will be text strings; and the rest is accomplished with a few hundred bytes of API calls.

Add another few hundred bytes of (not much) logic, round up to a kilobyte and add maybe another for general overhead.

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.

Re: Windows native app development is a mess

#228

Post by userbinator »

raw_anon_1111 wrote: post #71
samiv wrote: post #42

Earlier quoted context omitted.

To me this kind of "no need to change anything" implies stability but there's a younger cohort of developers who are used to everything changing every week and who think that something that is older than week is "unmaintained" and thus buggy and broken.

One of the earliest security issues that I remember hitting Windows was that if you had a server running IIS, anyone could easily put a properly encoded string in the browser and run any command by causing IIS to shell out to cmd. https://learn.microsoft.com/en-us/security-updates/securityb... I mentioned in another reply the 12 different ways that you had to define a string depending on which API you had to call. Ca…

Better to have known unknowns, than unknown unknowns.

Re: Windows native app development is a mess

#229

Post by ptx »

ack_complete wrote: post #220
gzread wrote: post #212

Earlier quoted context omitted.

First, dark mode is for people who set their screen brightness too high. Second, win32 is designed with the ability to change all the default colors and you used to be able to do this by right clicking the desktop and selecting "properties". If dark mode doesn't follow this - just another symptom of Microsoft's siloing incompetence. The team that wrote dark mode may not have been aware that this feature existed becau…

Dark mode for apps is a setting in the OS and a general expectation now, it's suboptimal to ship a new UI that doesn't support it. And, again, Win32 message boxes in your program will switch to dark mode whether you want them to or not. Win32 controls ignoring system colors goes much farther back than dark mode being introduced in Windows 10. The theming engine that broke a lot of that functionality was introduced in…

But they had dark themes for the XP theming engine, e.g. the Zune theme, didn't they? They could make the dark mode switch to a dark theme for XP-style themed controls and configure dark colors for the Win32 system colors.

Re: Windows native app development is a mess

#230

Post by bigstrat2003 »

The answer to your question of "why not Electron" at the end is: because then your app will suck. You've laid out the reasons why native apps are harder to make, but the reality is that Electron trades your ease of development for the user having a crappy experience. If you care about producing a good product, then you have to suck it up and make the native app even if it is harder.

Also, I think C# is miles better than TypeScript, but that's just my preference.

Post reply on HN