Hacker News Reader

Comment by cv5005 | Hacker News Reader

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?

View on HN

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.

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.

This is such a wonderfully beneficial comment to the HN community. It should get an award.

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.

We just built layers of shit over the ones we have.

They generally get the design right after some mistakes and are stabilizing it, when the new UI designers take over and want to re-do it from scratch.

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.

That's actually pretty close to my own career as well.

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

I recall there used to be a problem if you edited a (win)form in Visual Studio on a computer that didn't have the DPI set to 100% - did they fix that?

The work around was 'simply' to switch to 100% DPI scaling before opening Visual Studio. On my macBook Pro built-in monitor, this was not cool.

AvaloniaUI + MVVM toolkit.

I have no complaints using Qt for cross-platform development, it has been paying my bills for the last 15+ years.

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.

Tcl/Tk was also popular in certain niche products, like in RF test equipment.

It's still quite big in EDA (electronic design software).

Sorry, but this is simply just misinformation.

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.

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.

> as of the latest version, quite stable

Until the next latest version?

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.

And this already worked in OPENSTEP, like 30 years ago.

Programming with GUIs?

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.

Visual Studio and XCode are way, way overkill for most software and eventually constraining for bigger projects too.

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):

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

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

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.

> 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.

I would say having a good hot reload system gives you the benefit of wysiwyg with more readable code

> Avoiding the use of WYSIWYG editors when making GUIs is like avoiding the use of musical instruments when writing songs.

And yet, most songwriters write the song, they don't record themselves playing notes.

I encourage you to listen to the Song Exploder podcast to learn about how songwriters write songs.

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.

Yes, generations of Mac and Windows programmers have used GUIs to create their GUIs. Visual Basic, MFC + App Studio, .NET + WinForms, Interface Builder…

Given that the initial comment was complaining about a status quo, citing a status quo is an odd defense.

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.

How to add a button in SwiftUI:

    Button(“Click Me”) { buttonWasClicked() }

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.

This is total misinformation.

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.

Repeat after me: New! Fresh! Clean!

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.

https://learn.microsoft.com/en-us/security-updates/securityb...

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)

Better to have known unknowns, than unknown unknowns.

Except the former doesn't eliminate the latter

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

Doesn't WINE have pretty decent documentation by now from all the reverse engineering?

Wine cannot even install office 2014. It's not really as food as some claim sadly.

Lutris can up to 2016.

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

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.

That sounds like the same ugly hack that caused programs not to be “32 bit clean” back in the day for Macs

Ah yes, these 68000 pointers have a spare 8 bits for me to use! Because nothing will ever need more than 16 MB of memory. Sigh.

This is how pointer authentication codes work on Arm64.

It's all good if you have 128kb ram but they should have had a plan to escape it from day one.

One difference is that the Mac OS itself was not initially 32-bit clean, with the top byte being used by the Memory Manager.

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++.

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.

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?

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.

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.

I don't think it's abandoned and it looks like there is a lot of activity around the high DPI concern.

https://github.com/dotnet/winforms/issues?q=is%3Aissue%20sta...

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.

And for HiDPI, https://learn.microsoft.com/en-us/dotnet/desktop/winforms/hi...

I remember a marvelous quote from a guy that was at some MS conference and got handed a leaflet that said:

> WinForm or WPF, how to choose

and they were like: "the question I have isn't how to choose, but _why_ I have to choose".

It's been a while since I've touched it, but IIRC they made WinForms play with Hi-DPI nicely.

Windows dynamically sized is quite easy, people have had enough time to learn how to use layout managers in Windows Forms.

Naturally it is a bit more than just drag and drop controls from the toolbox.

HiDPI is supported in modern .NET, with additionally APIs, that aren't enabled by default only due to backwards compatibility.

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.

DevExpress has many advanced Winforms controls that are all GPU accelerated and super fast. So Winforms can certainly do GPU acceleration.

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.

And the 12 different ways to define a string depending on which API you call

‘Madness is something rare in individuals — but in groups, parties, peoples, and ages, it is the rule’ —F. Nietzsche

(tongue in cheek)

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.

I've always been able to post several replies in an hour before.

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.

Same here - our IOT device is a i5 running Windows IOT. Recently I switched from C++/Win32 to Golang and walk.

How does it look? I mean, what do the widgets look like?

This was an MFC project, so your old standard win32 common controls that looks the same since 98 or so.

and it would work on linux with wine lol.

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.

Most apps at the time managed that quite successfully. IIRC Adobe Photoshop was an MFC app. There was no other API but Win32 API.

Spotify would be remarkably improved if it became a simple enough gui to be excluded from this conversation.

WinAmp was the win32 music player of choice, once upon a time.

Once upon a time? I still use WinAmp every single day. It works great, does what I need, and I've never had a problem with it.

> Try writing something like Spotify in WinAPI and that's not even a complicated GUI either.

Fruityloops, now FL Studio, was written in Delphi and to my knowledge still is[1]. When ot launched there were no options but Win32 for Delphi.

That's just one example. Win32 makes it reasonably easy to skin things, and back in the 2000s a lit of programs did.

[1]: https://blogs.embarcadero.com/fl-studio-is-a-massively-popul...

> Win32 makes it reasonably easy to skin things

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.

But isn't that illegal now? You have to write everything in rust according to their cto.

Reply on news.ycombinator.com