Unless, of course, you tend to whine about "complex licensing", i.e. people wanting to make money as you do.
Windows native app development is a mess
411–420 of 481 posts
Re: Windows native app development is a mess
#412If you need low level access to the operating system and the hardware, you need Win32, so you need C/C++. And there's no way around it.
Expecting .NET apis to give you low level access in Windows is akin to expecting Go apis to give you low level access in macOS or using Haskell to interact with hardware on Linux.
Re: Windows native app development is a mess
#413Earlier quoted context omitted.
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.
Re: Windows native app development is a mess
#414The 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…
With WinUI 3 I did not even manage to render PNGs correctly. The colors were always slightly off and oversaturated, no matter what setting I used. I migrated the app to Tauri and the PNGs of course rendered perfectly. The implementation was much easier overall.
Native toolkits are usually more advanced and tend to properly support the colour profiles and allow for wider gamut output. Whereas historically the web had poor handling and would assume sRGB, causing more "washed out" output.
Re: Windows native app development is a mess
#415I wonder if Unity (the game engine) actually has a sneaky potential here. It’s cross platform, fast, and maybe just maybe less bloated than carrying around an entire browser like Electron?
Flutter is probably better suited for apps
Re: Windows native app development is a mess
#416Re: Windows native app development is a mess
#417Earlier quoted context omitted.
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…
I just had a look at two examples from that windows-rs repo. https://crates.io/crates/windows-sys https://crates.io/crates/windows Both seem to do the actual work in unsafe blocks, so I guess you could as well use C++, no? (only have limited Rust knowledge)
The unsafe code is written inside the library, which the user can contain in a safe API. With C++, the entire codebase is unsafe.
Re: Windows native app development is a mess
#418Re: Windows native app development is a mess
#419Nobody likes web technologies for desktop except lazy developers who know only that and try to make everything fit their world. WinUI3 is so buggy that not even their UI controls samples app can run for more than 5 minutes without crashing.
Pinvoke is reality on Windows and it is fine. COM is garbage but that's what we've got to maintain compatibility across 30 years. Windows is held by duct-tape and chewing gum and that is just reality
Re: Windows native app development is a mess
#420Earlier 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…
There can be other valid perspectives than your own.
I don't think your brightness sentiment is universally shared by most people, hence the downvotes. I think this comes from one particular study that people just end up parroting, possibly via third-hand gossip.
While a sufficiently low-brightness screen might have some specific advantages to dark mode, I think the issue is more nuanced than that.
First, not everyone can set their brightness to an appropriate level.
If the user is prone to migraines or light sensitivity, light mode even at a low setting could trigger headaches.
Light mode also produces significantly more blue light, which can have health side-effects as well.
If you keep a white screen on at appropriately low brightness in a dark room, the relative difference between the screen and the surroundings is still massive. This creates pupil strain as the eye constantly adjusts. Dark mode aligns the screen's luminance closer to the room's, reducing this strain.
Dark backgrounds make colors pop more vibrantly and prevent the "washed-out" look that can happen when bright images sit on a white background. It can also reduce halos visible around bright objects in photography apps and make the UI less distracting.
For battery-powered/mobile devices, dark mode uses much less battery power on OLED screens.