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 just kept working throughout the years.
2. I loaded the project into Visual Studio 2022, it converted from VC6 and compiled without problems, added the feature, shipped a new .exe to the customer, and it just worked.
What other platform has that backwards and forwards compatibility success story?
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 constantly change things because breaking backwards compatibility is Apple's kink.
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.
Tcl/Tk is pretty good in terms of rapid development. Unfortunately it has stagnated quite a lot over the years.
Gtk on the other hand is absolutely terrible and its developers don't help by completely rewriting things every few years and breaking all existing code in the process.
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.
I still think that WPF was the peak desktop UI framework. Extremely powerful with lots of small composable primitives, can easily do declarative but drop into more traditional event-driven imperative style where it makes sense.
I live in a bizarro universe where I started my career working on an expansive WPF desktop app on .NET Framework 4.0, and am still working on it now on .NET 10. From my perspective it's been WPF the entire time, and it's been pretty okay.
Similarly, I've been doing It development for pretty much the entirety of my career. When I see the struggles to make remotely useable apps in other frameworks I'm very happy I chose this path
This is patently false. To add a button to your UI, you open your window’s nib file Xcode/Interface Builder, click the plus button on the toolbar, and add a button. Then you control-drag from the button to File’s Owner and choose the method that you want to invoke when the button is clicked. Done.
Yes, generations of Mac and Windows programmers have used GUIs to create their GUIs. Visual Basic, MFC + App Studio, .NET + WinForms, Interface Builder…
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.
> 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've been a developer for a long time; I've built pretty large applications in all sorts of technologies and I now just prefer defining GUIs using text. Having a live GUI preview is great but actually dragging and dropping stuff is not more efficient to me.
To fit your analogy, using source code is like writing a song using musical notation. I'll write the song, then play it, and then go back to notation to fix it or expand on it.
In my experience drag-and-drop GUI editors work great until you add the constraint that the window has to be resizeable. Then it becomes a mess of clicking through dialogs for every UI element to make sure the anchoring and display flow is set up correctly, and you often have to go back and redo this whenever you add a new element or change the layout of the form. I think the best GUI programming experience I've ever had is on Palm OS simply because it had the constraint that every program always displayed in fullscreen at 160x160 (pixel-doubled to 320x320 on later devices) so you never had to deal with resizeable windows.
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 I built an iOS app using the xCode IB so that I could get up to speed more quickly, I really came to regret it several years into the project.
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):
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.
That feels like quite the exaggeration. If all you want is a button, all you need to do is initialize an NSButton and then tweak a few properties to customize it as desired.
If you want something more custom, subclass NSControl and you’re off to the races.
And if Obj-C isn’t your cup of tea, one can use Swift instead, even in a codebase that had been only Obj-C prior.
You can now use SwiftUI, which is, as of the latest version, quite stable. They used to change things a lot between releases a few years ago, but nowadays you don't need to refactor your code every year. Only issue with it is that it's iOS first, so you may need to fallback to AppKit (Cocoa) to implement more complex elements.
If you were doing "classic" Cocoa in the way it was intended, you wouldn't need to subclass anything for a simple button.
You wouldn't even need to write a single line of code, you'd just instantiate said button in Interface Builder, hook it up to a delegate (e.g. a window controller) and off you go. You can create a hello world example with a handful lines of code.
And even if you'd rather create the button programmatically, it's not much more involved.
Sure, if you're coming from Win32 and expect to program Cocoa without learning Cocoa, you're out of luck. But I guess that applies to all frameworks.
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.
What are you talking about? In Cocoa if you want a button you drag one in via Interface Builder. You don't even need to write any code. If you want it to do something, you type the name of the function it should call.
To me this kind of "no need to change anything" implies stability but there's a younger cohort of developers who are used to everything changing every week and who think that something that is older than week is "unmaintained" and thus buggy and broken.
One of the earliest security issues that I remember hitting Windows was that if you had a server running IIS, anyone could easily put a properly encoded string in the browser and run any command by causing IIS to shell out to cmd.
I mentioned in another reply the 12 different ways that you had to define a string depending on which API you had to call.
Can you imagine all of the vulnerabilities in Windows caused by the layers and layers of sediment built up over 30 years?
It would be as if the modern ARM Macs had emulators for 68K, PPC, 32-bit x86 apps and 64K x86 apps (which they do) and had 64 bit Carbon libraries (just to keep Adobe happy)
I think its at least as much of a working environment preference.
Once I became experienced enough to have opinions about things like my editor and terminal emulator... suddenly the Visual Studio environment wasn't nearly as appealing. The Unix philosophy of things being just text than you can just edit in the editor you're already using made much more sense to me than digging through nested submenus to change configuration.
I certainly respect the unmatched Win32 backwards/forwards compatibility story. But as a developer in my younger years, particularly pre-WSL, I could get more modern tools that were less coupled to my OS or language choice, more money, and company culture that was more relevant to my in my 20s jumping into Ruby/Rails development than the Windows development ecosystem despite the things it does really well.
Or to say differently: it wasn't the stability of the API that made Windows development seem boring. It was the kind of companies that did it, the rest of the surrounding ecosystem of tools they did it with, and the way they paid for doing it. (But even when I was actually writing code full time some corners of the JS ecosystem seemed to lean too hard into the wild west mentality. Still do, I suspect, just now its Typescript in support of AI).
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.
Well it's still a 32 bit program so I guess that helps.
Would probably require some porting to make it 64 bit native, but as long as you use the WPARAM, INT_PTR typed and what not correctly it 'should just work'.
Yeah that's the bulk of the work for migrating small Win32 apps. Things escalate when someone has built their own dynamic GUI framework over Win32, used a range of GUI controls, and then built event-driven apps on top of that, it's a lot lol
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.
How do Linux and Java do it, when you want to compile your program in both 16-bit char and 8-bit char mode? Oh that's right, you don't.
You can pick one or the otherfor Windows too, so don't ask me why it's done that way. It was originally so you could compile for both the new hotness Unicode, and the old compatible ASCII.
Partly because Microsoft resisted UTF-8 forever, and so using the ANSI/multibyte strings didn't therefore give you modern functionality. Why they didn't implement Unicode for Win95, I'm just not sure. If they had, the only reason to compile an ANSI version would have been to target Win32S (Windows 3.11).
Or, they could have implemented a UTF-8 code page for Win32 as soon as it was available and then most software could just use byte strings.
In 32-bit windows, you used to be able to see if a pointer was valid or not by seeing if it pointed to the last 2GB of address space. If it did, it was pointing to Kernel memory that was not valid for user mode code.
But then Large Address Aware (4GB limit) changes everything, and you can't do that anymore. In order for a program to be Large Address Aware, you need to not try to do things like check high bits of pointers, then every single library and DLL you use also needs to do the same.
Win32 programming has been reduced to a small niche now. Even 20+ year old Win32 books don't cover things in-depth (or practical use cases) let alone the 32bit->64bit migration
Yeah that doesn't always work that well. Think you were lucky.
Add high DPI to the mix and things get rough very quickly. Also the common control have weird input issues (try ctrl+backspace in an Edit control). All those little things need to be fixed carefully for something to be ok in 2026.
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.
I assume that if Microsoft hadn't abandoned WinForms for the next thing, it would support dynamic sizing and DPI properly. It's mindboggling how much time and effort they've wasted coming up with new GUI frameworks instead of just improving on what they have.
It does, but many still think it is like using VB 6 and don't learn the additional APIs that provide that support, e.g. FlowLayoutPanel and TableLayoutPanel.
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.
transparency as well. WinForm really struggles with the idea of stacking elements on top of one another where there is an arbitrary amount of transparency or tricky shapes. Its just not worth the hassle compared to WPF.
I've not done MFC Win32 programming since 1999 but if I recall those programs don't execute the main() function. They instantiate the Win32 class for your app or something like that. I can't remember any details anymore.
You still have a main function in Win32, it's just called WinMain and has a slightly different signature.
MFC has CWinApp, which you'd normally subclass, and a stock WinMain implementation that instantiates that, but it's not strictly necessary to subclass it, just convenient.
They don't use main because they use WinMain, which is the entry point for Windows apps that don't run in a console window.
WinMain should create an instance of the app class and call Run.
"You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 which feels pretty unfair
> "You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 which feels pretty unfair
I get that if I post more than six replies in an hour.
But that’s the point the article’s making. At the C level you’ve got a fully functional system. Above that level (even at the C++ level), feature support is a mess.
Honestly, your GUIs are too simple to be part of this conversation. Try writing something like Spotify in WinAPI and that's not even a complicated GUI either.
Actually it doesn't. Win32 skinning is either making a control completely from scratch or hacking into undocumented aspects of the native controls - i.e. what WindowBlinds does. AFAIK modern Delphi has some component that basically follows the WindowBlinds approach.
> Win32 skinning is either making a control completely from scratch
In almost all cases you just need to handle the drawing yourself, and you get fairly broad access through the API to do so through the various non-client and client window messages.
Now, Windows has gained some newfangled components over the years with more or less integration, I'm thinking basic Win32 controls.
What all cases? Windows (basic Win32 at that) provides a lot of controls like buttons, checkboxes, inputboxes, scrollbars, radiobuttons, comboboxes, listboxes, etc which do all their drawing themselves and you do not have any way to fully skin them (without hooking into undocumented stuff). Some controls allow for custom drawn elements but pretty much always that is just for the elements themselves, not the entire control.
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 just kept working throughout the years.
2. I loaded the project into Visual Studio 2022, it converted from VC6 and compiled without problems, added the feature, shipped a new .exe to the customer, and it just worked.
What other platform has that backwards and forwards compatibility success story?