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

181–190 of 481 posts

Re: Windows native app development is a mess

#181

Post by ack_complete »

pjc50 wrote: post #18
LAC-Tech wrote: post #13

Earlier quoted context omitted.

Winforms? lol at them still bekng the best option. so much wasted effort trying to replace them

Winforms is great until you try to make windows dynamically sized, or deal with DPI nicely. In every other regard it's still fine, and for accessibility actually _better_ than many subsequent frameworks. And produces nice small fast executables.

Or, unless they've changed it, hardware accelerated rendering. Winforms was based on System.Drawing, which used GDI+, which was largely software rendering. This was confusing because GDI+ was not really related to GDI, which had and still does retain some hardware acceleration support. Even basic color fills start becoming an issue with a big window/monitor.

Winforms is also .NET based, so it's inaccessible if you don't want to write your UI in and take a dependency on .NET.

Re: Windows native app development is a mess

#182

Post by NetMageSCW »

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.

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.

Re: Windows native app development is a mess

#183

Post by NetMageSCW »

criddell wrote: post #117
jordand wrote: post #17

Earlier quoted context omitted.

The one big challenge I've had with big legacy Win32/C++ codebases is migrating it fully from 32bit to 64bit. Loads of know-how and docs for complex GUI controls and structs are lost to time, or really fragmented. Other than that, yeah it really does all just work once you're past that.

I went through that a few years ago and it actually went pretty smoothly. There were a few UINT_PTR or DWORD_PTR changes I had to get used to and a couple of string glitches (we mostly used the _T() macro for strings and already used the _t variants of string functions in the original code, so that helped). The biggest problems were DAO (database) and a few COM controls that were not available in x64.

Having to use macros for literal strings in your code is just incredibly stupid of Microsoft and/or C++.

Re: Windows native app development is a mess

#184

Post by markus_zhang »

user____name wrote: post #45
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 feel like I'm the only person in the world who would rather write ugly win32 jank for the rest of my days than ever having to touch an "elegant" or "well structured" Cocoa codebase. In win32 if you want a button you call a function and pass a hande, in the Apple world you first subclass 7 interfaces in some unreadable Smalltalk-wannabe syntax and pray you don't need to access the documentation. And of course they c…

I'm probably another, but I have never done any professional Win32 work. You know, those kind of jobs are rare now and I doubt they want anyone without experience.

Re: Windows native app development is a mess

#185

Post by NetMageSCW »

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

That’s ironic given that the new Outlook and Teams are a mess because they are web apps instead of native apps.

Web apps cause have lots of trouble emulating proper native look and feel and often have wierd issues with things like consistent focus and keystroke navigation. They have all the dumb issues of Java apps with no improvements beyond not being Java and are slower and more memory heavy to boot!

Re: Windows native app development is a mess

#186

Post by ack_complete »

apankrat wrote: post #114

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 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 window messages for changing control colors are silently ignored with theming is enabled. Menus are among the more difficult to deal with as they require extensive owner draw.

On top of this, there are a small handful of system UIs that do support dark mode and make your program look inconsistent with dark mode regardless. Message boxes will switch to dark mode, and so will file dialogs -- which is a problem if you've used the Vista-style customization, as any syslinks will appear in a color of blue that's hard to read against the dark mode background.

Re: Windows native app development is a mess

#188

Post by NetMageSCW »

jayd16 wrote: post #85
sylens wrote: post #37

Author raises several good points. Why isn't the latest .NET runtime pulled down into Windows 11 devices via Windows Update? Why isn't there a better path forward for deployment? It's another example of how they have completely abandoned any attempt at providing a good user experience across their products

Windows update is how it used to work and it's terrible. An update breaks old apps, or downloads a every single version (not feasible). Who would want to run windows update to install a new app? It's just a bad idea. Today we just pack in the DLLs and it just works.

No one suggesting using Windows Update to install new apps, they are suggesting the current .Net framework should be elevated to a first class Windows citizen and included with Windows installs and updated with Windows Update, and that seems like and obvious idea that should have been implemented when .Net Core became .Net.

Re: Windows native app development is a mess

#189

Post by Rohansi »

sylens wrote: post #37

Author raises several good points. Why isn't the latest .NET runtime pulled down into Windows 11 devices via Windows Update? Why isn't there a better path forward for deployment? It's another example of how they have completely abandoned any attempt at providing a good user experience across their products

I'm assuming but the versions are not fully backwards compatible so you can't just ship the latest version, they would need to ship all. There almost ten .NET versions released after the one which ships in Windows. And a new version is released every year.

The author does mention that .NET does have distribution options which don't require the user to install the runtime. You can have it package the full runtime with your build, either as a bunch of files, a self-extracting executable, or a standalone AOT-compiled native executable.

The author mentioned that the AOT-compiled executable is 9 MiB which is unacceptable to them. The other options will need even larger. Personally I don't see 9 MiB as a big deal especially when the author would rather go with Electron which is larger at worst (bundled Chromium) and only inefficient at best (system WebView).

Re: Windows native app development is a mess

#190

Post by Rohansi »

NetMageSCW wrote: post #188
jayd16 wrote: post #85

Earlier quoted context omitted.

Windows update is how it used to work and it's terrible. An update breaks old apps, or downloads a every single version (not feasible). Who would want to run windows update to install a new app? It's just a bad idea. Today we just pack in the DLLs and it just works.

No one suggesting using Windows Update to install new apps, they are suggesting the current .Net framework should be elevated to a first class Windows citizen and included with Windows installs and updated with Windows Update, and that seems like and obvious idea that should have been implemented when .Net Core became .Net.

.NET versions are not fully backwards compatible. Would you like every Windows install to ship with over ten versions of the .NET runtime?
Post reply on HN