Live data from Hacker News

Windows native app development is a mess

domenic.me

231–240 of 481 posts

Re: Windows native app development is a mess

#232
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…

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.

Re: Windows native app development is a mess

#233

Earlier quoted context omitted.

> 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 on…

Yes, that is true, but in practice nobody has ever done that. And the material complexity of offering that mode is higher than just dynamically linking the library.

Also, modern compilers make this method much harder to use. It is much harder to stably relink object files like that than to just use the normal dynamic link method.

Re: Windows native app development is a mess

#234

Let me chime in and say that plain Win32 API is a perfectly viable option if you are using C++ (or another "OO" language) and if you are willing to sink a couple of weeks into writing your own MFC-like wrapper. Clearly this is not an option for those who are just starting up with Windows GUI work, but with little experience it is really a matter of 2-3 weeks of ground work and then you have full control over all nuan…

The last time I built a native Windows app years ago, I used WTL 3.0. It’s a light weight wrapper on the native Win32 API, lighter than MFC. It took out the unpleasantness of working directly on Win32 API and wrapped it in a simple OO framework. It had access to all features of Win32. It could produce runtime binary in dozens of K, instead of MB or GB.

Microsoft released it open source later on. Looking at the repository, looks like it has been kept up and maintained, up to version 10 now.

Re: Windows native app development is a mess

#235

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?

Re: Windows native app development is a mess

#236
post #56
post #3

> And from what I can tell, neither are most developers. The Hacker News commentariat loves to bemoan the death of native apps. But given what a mess the Windows app platform is, I’ll pick the web stack any day, with Electron or Tauri to bridge down to the relevant Win32 APIs for OS integration. Well yes as a user I prefer native apps for their performance. It's clearly a mess to develop native apps as the article sh…

When Microsoft themselves use electron to develop apps what expectations can we have on other devs?

Considering people are leaving Windows in part because Microsoft is shoving web slop into it, perhaps other devs should learn the lesson that it's not acceptable to use web frameworks on the desktop.

Re: Windows native app development is a mess

#237
I used to code Win32 around the Win 95/98/2000 era (my first VC++ was 1.0 for 16bit) but switched to BSD and Linux around 2000 and haven't looked back. I avoid Windows as much as possible and did learn about .NET and how slow it was but I'm a bit shocked that Win32 is still a thing and still being recommended. Sort of makes me happy and sad at the same time...

Re: Windows native app development is a mess

#238
post #195

Earlier quoted context omitted.

Why single out WebViews? Would you consider Flutter native? It renders widgets on its own just like a WebView does.

Most toolkits, including WebUI 3.0, render widgets on their own, so you can't distinguish just on that. I'd say anything written in an interpreted language is not native, and Javascript falls into that category. Dart at least is possible to compile ahead of time, and so is C#.

WebViews aren't written or rendered with interpreted languages either. It is also usually not Javascript that makes browser based apps so heavy. It is almost always the whole browser stack that is making them large and memory hungry, which is mostly written in C++.

You can also hook a WebView up directly to a low-level language and skip Javascript entirely, so does that mean Rust + WebView = Native?

Re: Windows native app development is a mess

#239
It had been many years since I last developed a desktop app. A couple of weeks ago I used Tauri to create a simple app for Windows and Mac. Developing the app was easy with Claude. Building the app for different platforms and architectures was easy with GitHub Actions.

But after I had the msi and dmg files, my non-techy colleagues couldn't install the apps because they weren't signed. The workaround for Mac was fine (remove the quarantine attribute on the installer) but for Windows my colleague had to disable Smart App Control (SAC), which cannot be re-enabled without re-installing Windows.

I get the point of these protections, but the difficulty of getting past them surprised me. I thought that on Mac you should just go to settings -> security and click 'Allow Anyway'. And that on Windows you'd get a GUI warning that would need admin privileges to get past. But MacOS needed a terminal command, and Windows needed a control panel setting change.

Re: Windows native app development is a mess

#240
post #161

Earlier quoted context omitted.

>Native means system libraries only. Since when? To me, anything not webview-based is native, though you have varying degrees of integration into the platform.

Why single out WebViews? Would you consider Flutter native? It renders widgets on its own just like a WebView does.

For me, native means "I can integrate a platform widget in the middle of it". For instance, with Qt, GTK or wxwidgets it's entirely possible to integrate a Win32 / Cocoa / X11 component right in the middle of your app (and it's super important for instance for things such as integrating audio plugins, where the plugin only gives you a HWND or NSView and you have to draw your application Chrome around it, have it follow resizes, etc.)
Post reply on HN