Live data from Hacker News

Windows native app development is a mess

domenic.me

361–370 of 481 posts

Re: Windows native app development is a mess

#361

One of the challenges with the older methodologies was getting the damned things to look good. I distinctly remember with WinForms having to use DevExpress to get the theming to look moderately modern. Bit I still never bothered with the later approaches because it looked like I was going to lose out on speed and ease of development. WinForms may have looked ugly but you could bang things together pretty quickly.

I feel like WinForms was peak (because it was close to Delphi) and it went downhill from there.

IMO WinForms didn't manage to reach even Delphi 2's state, so i'd say it is far from peak considering the improvements later Delphis (and now Lazarus) added. It was abandoned too soon.

Re: Windows native app development is a mess

#362
What kind of experience you have is about what kinda of developer you are. If you're the kinda programmer who wants to use all the newest versions of stuff because you think it'll be better, then you'll be in an endless quagmire of hitting limitations.

Most web programmers fall into that bucket for example. If you're the type to recoil at XMLHttpRequest, reaching to fetch or other even newer stuff. Then you'll balk at Win32 and be in a never ending pit of new Windows technology. I'd argue this is true of basically all new software. It's worth starting with whatever the oldest most compatible version of your target and ignoring the advertising and hype.

Re: Windows native app development is a mess

#363
post #215

Earlier quoted context omitted.

Why wouldn't you program a GUI with a GUI if one is available? Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.

I'm not saying you should never program with a GUI, but it comes at a cost of being able to read the code and tell what the result of the code will be, and all the associated benefits of version control and code reviews that you lose. And as a side-effect of that, merge conflicts become murder when your "Fix right-hand margins" commit with a 20 line readable +/- diff instead becomes a 1000 line +/- diff. The one time…

If this is a real issue, it seems to be an issue with the way a particular toolkit handles visual WYSIWYG editors. Lazarus serializes the object properties into a simple and readable text format that follows the class declarations themselves and you can easily diff them. E.g. here is the diff of a minor change i did (added a new button in a panel with an event handler and modified a property in an existing button):

https://i.imgur.com/aHMHqSc.png

Handling merges (and other VCS functions) is also simple since you can edit the file manually if needed.

Re: Windows native app development is a mess

#364

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…

Using Win32 to write a UI in Windows is like pulling teeth. There are bindings for Rust but even still it's a nightmare.

MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell.

I think it's fair to say that the entire story for native app development is a mess - which is most likely why Electron became so popular. There just isn't a practical sane alternative.

Re: Windows native app development is a mess

#365

Earlier quoted context omitted.

Sure, if I'm building something for myself or fellow hobbyists this approach works (though in that case I'd prefer a good TUI/CLI). But if you're building an app for the average person, how it looks has a big effect on whether they choose it over an alternative.

Programmers and designers thinking the average person is a moron is one of the two reasons almost no good software is writren today.

What's the other reason?

Re: Windows native app development is a mess

#366

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…

IDK man, I wonder how TF did the creators of Winamp do it? Were they so much smarter than the programers of today? And Winamp 2.95 still works on WIndows 11 today. IIRC Borland Delphi was the most popular tool back then for making Win32 apps since it was so easy to use.

> Were they so much smarter than the programers of today?

Unironically the answer is yes. I've been watching this for at least 15 years.

I think one inflection point is when everybody who was coming up became accustomed to GC languages. Within a decade of that trend starting, nobody could reason about memory anymore.

With the AI boom we're going through another inflection point. When coding is synonymous with using an LLM, nobody will be aware of how anything works (or doesn't)

Re: Windows native app development is a mess

#367

> However, for no reason I can understand, Microsoft has decided that even the latest versions of Windows 11 only get .NET 4.8.1 preinstalled. .NET has new releases every year, supported for 2 or 3 years. That’s not really compatible with Windows release cycles. Also, if Windows 11 25H2 shipped .NET 8, and now Windows 11 26H2 would ship .NET 10, apps which depend on version 8 might break. Easier to just think of .NET…

.Net has always been hugely backwards compatible and breaking e.g. .Net 8 apps which will run out of support in November 2026. How is constantly needing to update .Net any different from constantly needing to update any other part of Windows? Ideally they would just install newer .Net releases side by side and uninstall .Net releases as they drop out of support.

.Net releases are installed side-by-side. I agree with the Author that a more recent minimum install of the framework would make sense, especially with the existence of LTS releases of .net [1], seems to be every 2nd major version. I don't agree with the argument that Windows would have to guarantee a particular version is installed. If an app requires .net 8 and .net 10 is installed, the app can install .net 8 next to version 10. It would however require different silos within Microsoft to communicate and plan together.

.Net 4.81 is the last one before .Net Framework was unified with .Net Core. It's very legacy by now, but there would be many enterprise/business apps that still require it.

[1] https://dotnet.microsoft.com/en-us/platform/support/policy/d...

Re: Windows native app development is a mess

#369

I’m still confused which frameworks are tied to which “visuals”. Ignoring the web-frameworks, do Win32 apps inherently look like Windows XP buttons or can they look more modern? It might be nice if the article could add screenshots, a few of the Wikipedia links have a screenshot, but again I’m not sure if you’re limited to that UI or not. I also like the carousel in the article showing the tray menus, but again not s…

From what I understand, Win32/MFC/WinForms inherently are stuck around Vista visuals, with no dark mode support. Win32/MFC also have no high-DPI support, so you get gross upscaling. (WinForms supposedly has some support for high DPI, but with many open issues. [1]) Now, I'm not 100% sure, since there are so many commenters in this thread saying "just use Win32/MFC like a real man". (Most of them ignoring the memory s…

I have 15 year old binaries made with WinForms that look just fine on Windows 10, and use native Windows 10-styled controls.

Re: Windows native app development is a mess

#370

Earlier quoted context omitted.

I'm not saying you should never program with a GUI, but it comes at a cost of being able to read the code and tell what the result of the code will be, and all the associated benefits of version control and code reviews that you lose. And as a side-effect of that, merge conflicts become murder when your "Fix right-hand margins" commit with a 20 line readable +/- diff instead becomes a 1000 line +/- diff. The one time…

If this is a real issue, it seems to be an issue with the way a particular toolkit handles visual WYSIWYG editors. Lazarus serializes the object properties into a simple and readable text format that follows the class declarations themselves and you can easily diff them. E.g. here is the diff of a minor change i did (added a new button in a panel with an event handler and modified a property in an existing button): h…

I swear I meant to write an "often" in my previous post. But yeah, that was largely directed at the interface builder in xCode, for iOS - it gives you storyboard/xib files that are effectively-not-human-editable (and entirely non-mergeable) xml.
Post reply on HN