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.
Windows native app development is a mess
361–370 of 481 posts
Re: Windows native app development is a mess
#362Most 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
#363Earlier 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…
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
#364I 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…
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
#365Earlier 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.
Re: Windows native app development is a mess
#366I 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.
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 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
#368Re: Windows native app development is a mess
#369I’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…
Re: Windows native app development is a mess
#370Earlier 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…