Comment by userbinator
15 days ago
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 borderless, titlebar-less, non-activating black windows
Creating non-functional windows is trivial. Another few hundred bytes at most.
Intercepting a global keyboard shortcut
A few dozen bytes to call SetWindowsHookEx.
Optionally running at startup
Write to the appropriate registry key. A few hundred bytes.
Storing some persistent settings
Ditto. Another few hundred bytes. You can use a .ini file too, for around the same size.
Displaying a tray icon with a few menu items
Most of this size of this will be the icon itself - a few kilobytes; the next biggest contributor will be text strings; and the rest is accomplished with a few hundred bytes of API calls.
Add another few hundred bytes of (not much) logic, round up to a kilobyte and add maybe another for general overhead.
But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
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.
The sane alternative is macOS because there is one thing that Windows lacks; a community. Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.
When I look at the apps on Windows, all I see are abandoned projects and MVPs with a borderline malware financial structure.
> Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.
Microsoft has had even more people working on Windows software..
"Developers, Developers, Developers!" - Steve Balmer
Microsoft has always had vastly more developers and development of software for Windows.
Apple still after all these years has a tiny market share of overall platforms, software, all of it really.
Not sure how you can suggest Apple is somehow the bastion of software development. If you write mac software, you'll be targeting a platform with 15-20% market share at best.
7 replies →
Really?
I've been a fulltime Linux user for years but there are tons of excellent Windows-only apps.
Here are some that I miss: Directory Opus, ShareX, Wiztree, Everything, AltDrag, AutoHotkey, Paint.NET, irfanview, SumatraPDF. I'd add Keepass2 as well but fortunately KeepassXC is a thing.
Those are all feature-filled (in the bloat-free good way) and they've all been around for over a decade (from memory). Most are free and open source to boot.
1 reply →
To be fair, these exist on Windows as well. There's some cool stuff, MyLifeOrganized for example I would consider to be on par with OmniFocus.
But I agree that most of the boutique stuff on Windows gets drowned in all the enterprise software a bit.
1 reply →
I think the biggest reason for Electron is that marketing don't care about native UX but obsessively try to ram the branding down the users' throats.
With electron this is much easier because nothing is native and it looks and feels just like the website.
Linux as such has no UI - which framework specifically were you thinking of?
Qt or GTK
It’s certainly doable, but not as nice and easy as Delphi or Qt, which are WYSIWYG.
Of course, if one is a web developer, even attempting such a feat this could result in a brain-melting experience.
What about Qt? I am asking - I really don't know.
Win32 is easy: https://news.ycombinator.com/item?id=40085237
Comparing oranges to apples. Win32/Win API is (one of) the native API to do Windows programming.
Pure C is not the native way to do application programming on macOS. As I mentioned elsewhere, you can bring up a window with a button with no code on macOS. You can make that button show a string on a label with a handful lines of code.
Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it is to be considered in certain situations.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are still some reasons to do so, of course, but Win32 isn't one of them -- one can use it from a memory safe language just fine, e.g. https://github.com/microsoft/windows-rs
A good rule of thumb for programming languages is to check what the general recommendation is on HN and do the opposite.
Using win32 from Rust is nonsensical. This is the kind of use-one-tool-for-any-job Visual Basic 6 programmers used to have, except VB6 would have actually been much better than Rust at Windows programming.
My reply was about Win32 and typical C++ development. Obviously other projects may be best written in C# or other languages and frameworks.
Anyway, Microsoft is the one providing the Rust crate(s) I linked, and according to the releases it seems they are using them internally too. I do not see what is "nonsensical" about using them, and I have used them in the past just fine, just like I used Win32 from C++ in the past.
I just had a look at two examples from that windows-rs repo.
https://crates.io/crates/windows-sys
https://crates.io/crates/windows
Both seem to do the actual work in unsafe blocks, so I guess you could as well use C++, no? (only have limited Rust knowledge)
Unsafe blocks are common when interfacing with C or C++ code.
The first thing you want to ensure is that you avoid unsafe in YOUR code. That is, after all, where you are going to create your bugs.
Ideally, there is no unsafe code in the crates you use. If there is, at least there are more eyes on that code to catch problems. You can inspect and debug that code, and others can do it for you. Others may battle test it and stress it far more than you will.
And at least the unsafe code is isolated to a few areas in the supporting libraries. Less to inspect. Less to debug. Fewer places to introduce memory related regressions.
It does not at all follow that, given an unsafe block, we may just have well used C++.
> so I guess you could as well use C++
The unsafe code is written inside the library, which the user can contain in a safe API. With C++, the entire codebase is unsafe.
It's straightforward to contain the unsafe usage and potentially write safe wrappers and structures around it. Memory bugs mostly stem from the larger application in conjunction with the API anyway, rarely only the API layer.
> Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project.
Yes, you may be harmed by proper IDE and debugging experience via Visual Studio.
I like Visual Studio, and have used it for C++. And, yes, it would be great if they add native support for Rust.
But that would not make me pick C++ over Rust. Other requirements may.
I was gonna say he addressed Microsoft's rust library, but apparently that was something different?
https://github.com/microsoft/windows-app-rs#this-repository-...
I'd say it's confusing but I wouldn't expect any different from Microsoft.
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)
Also a lot of people got into the industry because they saw the salaries of programmers, but have no real passion for computers or software. They did the studying enough to pass the tests and write an algorithm to pass the interview and land a job. But they don't have the drive to make things better, think outside the box, or write something they can be proud of.
AI has accelerated this because it's becoming harder to detect the frauds.
The web and web apps as pushed by Google and others was another nail in the coffin of efficient software.
From Android to whatever web framework they’re peddling as development solutions, these are not designed for efficiency, but for time-to-market and consumption by front-end developers.
> became accustomed to GC languages
There is a certain amount of truth to that I think
I do not think anybody was “smarter”. There were smart and less smart people then and now.
But the “typical” practice changes. And that changes what you get. I think your “typical” programmer is more productive today in terms of what they can accomplish. But that work is going to be built at a higher level of abstraction and likely a lower level of run-time efficiency. As a percentage, fewer people understand or take into account the lower level details.
It is not just about new tech. After all, I can write all my code in RISC-V assembler. And I can manually allocate memory and manipulate pointers in C#. It is just not what people normally do these days.
Were they so much smarter than the programers of today?
The average programmer back then was probably far more knowledgeable of the low-level details.
I worked on Windows programs similar to WinAmp, which had custom drawing, skins with custom shapes, etc. Usually written directly in WinAPI, VCL (C++ Builder, not Delphi) or a combination.
It was a matter of having access to the right (although limited) resources such as Petzold’s book, Codeproject and experimentation. There was no big rush, no start-up hustler mentality and most importantly hardware resources mattered a lot and it was a point of pride to create efficient software.
The development culture of present time is the opposite of that: developers are drowning in documentation, the default solution is technically inferior and the hustler mentality’s dominating.
https://github.com/alexfreud/winamp : does indeed look like classic Win32 in the files I randomly tried, although there's also a QT DLL and a whole load of other stuff on there.
Software seems to have quality and capability as diametrically opposed attributes.
Yes, of course they were smarter.
If you don't want to spend quite so much time byte shaving, and you don't want to deal with memory safety or _UNICODE, you can do it in .Net Framework in half the time.
How do you make your win32 app look good to the average person?
Depends what you mean by "look good".
The main function of the app being discussed here is to draw solid black rectangles on the screen.
Don't forget the "average person", I'm assuming someone relying on software as a tool, doesn't care about the stuff "designers" seem to obsess over, and will actively hate if you break their workflow by doing things like adding useless padding that makes them scroll more or shows less information in the name of "modernity". There's a lot of specialized niche software for various industries, often very expensive too, which looks like it came out in the early 90s. As long as it works well, users won't complain.
Oh, how I hate when vendors bring "modern web" aesthetics to desktop utility programs. For example, Docker Desktop could go a long way in terms of usability if it just sticked to Win32 common controls - the kind of buttons, labels and list views that have been around since Windows 95. Maybe I wouldn't even have to wait 10 seconds for the main window to show up every time.
There's a pretty simple settings window: https://github.com/domenic/display-blackout?tab=readme-ov-fi...
Would that UI be hard to accomplish?
10 replies →
I used to work in finance. Screens very densely packed with text is the preferred user interface.
We did a UI refresh at one point. It looked much nicer. People hated it. We had to hastily redesign it again and it looked far more like the original.
If your application saves me time (is intuitive) or enables me to do tasks that I couldn't do before (is powerful) then I don't care one whit what it looks like. As long as it doesn't actively hurt my eyes to stare at you can do whatever you want.
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.
4 replies →
They really don't. Though if Microsoft wanted to, they could solve that too. For example, the OS control panel used to be extendable. Technically still is, just not the new one (and of course both remain). Then you could have this UI or something very similar to it right in there.
Several integration points like this have been removed, supposedly because third party software was just too bad in how they used them, causing issues. Or at least so goes Microsoft's perspective. Personally, I find that very believable! If by integration points the only thing one can imagine is calling into random third party code on the regular that the user has installed, bang spank in the middle of critical user flows, on the same thread and in the same process as itself, that's exactly the kind of grief I'd expect to occur...
If only there was a way to provide a way to craft e.g. custom flyout menus for the taskbar or custom pages in the Settings app, without invoking arbitrary third party code and possibly causing crashes and hangs in system apps and menus... or just not letting crashes and hangs affect the application (e.g. Windows Explorer) calling them in the first place.
Disable borders and design your app nicely with images to replace standard user input elements.
That sounds like a great way to make a mess. Look at Microsoft's own apps shunning proper File dialogs and instead presenting a giant, bizarre pane of mostly text and a few crudely-drawn boxes in order to save a file. You have no idea what you're looking at or where you are in the file system.
Then there's the removal of title bars from Windows. You often have no idea what app you're looking at. Pull up a PDF in Acrobat and also in Edge. Now, at a glance, which is which?
Regressive garbage.
3 replies →
A couple of weeks ago, I decided to write a GUI utility to propagate my new PuTTY default settings to existing sessions. I took the Go Walk package, which is Win32, and was done in several hours, most of those spent hunting down an obscure layout bug. So long with memory-unsafe languages.
Here's the source code for those who are interested: https://github.com/sergeax/stamputty
I made an app using Win32 in Golang. It controls my monitors' brightness and "true-tones" them to match the sun cycle via DDC/CI. It has autostart, global hotkeys, persistent settings, sits in the tray, silent auto updates etc.
The hard parts were seeded by Claude Code. Happily maintaining and modifying it for close to 3 months now. Just a data point, especially about not needing C++.
There were decent and reasonably thin layers over that to solve the immediate practical issues (e.g. Delphi, MFC), but they're no longer fashionable and nothing seems to have replaced them in the same space. Maybe we need a "NoFramework" phase to get back to RAD again?
>> But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.*
Eh. I spent many years writing cloud/backend software on the JVM, in between stints writing desktop software. When I was first writing desktop software, it was all in C and C++, and I got used to it, but it wasn't pleasant.
When I came back to writing desktop software in C again (just a few years ago), after writing in memory-safe languages for so long (Java, Scala, Rust, Go), I found going back to C to be just so tedious and annoying. It's just incredibly unpleasant to be chasing down segfaults and data races and crap.
So I think saying it's a "crime" is hyperbole, but even for apps that don't have untrusted input, it's still much more pleasant writing in a language that doesn't let you write memory safety bugs.
(Absolutely agree with you on how it's possible to make nice, small, non-trivial Win32 apps, though I haven't done Windows app development in a couple decades. But I think a lot of people would save themselves a lot of time and headaches if they reached for .NET or something higher level.)
This is the way. Everything is fine if you are a responsible dev that writes secure code. You can very clearly see the pattern of shitty framework after shitty framework coming and going. Why bother when the C++ code will outlive whatever shitty framework is coming next?