7 ms·

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 requ

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.

feznyng 7mo ago
How do you make your win32 app look good to the average person?
- themafia 7mo ago
  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.
  - feznyng 7mo ago
    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.
    - rkagerer 7mo ago
      It's funny, the "modern" look has become a countersignal for me. If the app looks like a webpage, I instinctively don't want it. Not because of aesthetics, but simply because I've come to associate that style of appearance with a lack of (or awkward) keyboard shortcuts, featuresets dumbed down to a level appropriate for chimps, various nags injecting friction against getting work done (ads, feature tours, logins, update reminders, etc) and laggy, resource-squandering performance thanks to some kind of bloated rendering framework like Electron with multiple V8 hosting processes sprawled across chrome.exe instances or whatever. Case in point, the Dropbox Simplified Desktop App was a huge improvement for me. It nails just about everything I ever needed their app to do, and removes all the user-hostile fluff I never asked for. Similarly, I found Windows 11 Enterprise IoT LTSC to offer an improved desktop experience compared to traditional Windows, thanks to its exclusion of a lot of the cruft Microsoft otherwise shoves down the throats of users who, as far as I can tell from frank discussions with many of them, likewise actively don't want. I'm not saying your desire to make your app look polished means it's crap, but beauty is in the eye of the beholder. Just like fashion, I wouldn't be surprised if we see a shift in the aesthetics trend as more people discover a retro feel sometimes signals a better user experience.
    - nananana9 7mo ago
      Programmers and designers thinking the average person is a moron is one of the two reasons almost no good software is writren today.
      - SoftTalker 7mo ago
        What's the other reason?
        nananana9 7mo ago
        That most programmers are not that great at programming, and wouldn't be able to produce high quality software even if that was their stated goal.
- userbinator 7mo ago
  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.
  - deleted 7mo ago
    [deleted]
  - lelandfe 7mo ago
    There's a pretty simple settings window: https://github.com/domenic/display-blackout?tab=readme-ov-file#screenshots https://github.com/domenic/display-blackout?tab=readme-ov-fi... Would that UI be hard to accomplish?
    - bloomca 7mo ago
      You mean conceptually or to match it? Native components are pretty much impossible to match without actually using the native framework which provides them, so you need WinUI/WPF. Win32 provides its own components which are basically Win95 style apps, and you can draw the components using some graphics APIs by yourself. The whole native development area is a mess exactly because making your own (decent) renderer is a huge undertaking.
      - Onavo 7mo ago
        But you are making false equivalence, the Win32 GUI API is decades out of date from modern UIs. I can use flutter and make a pixel perfect equivalent of the above UI in an hour, with the exact same responsiveness behavior on both windows tablets and desktop, and scales perfectly in high DPI displays. 3 hours if you want the toggle animation timing to be exactly the same. I came from the WinForms world so don't pretend I don't understand Win32 programming. The fault lies with Microsoft for not investing in it more.
- alt227 7mo ago
  Disable borders and design your app nicely with images to replace standard user input elements.
  - VerifiedReports 7mo ago
    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.
    - p-t 7mo ago
      > removal of title bars they did what??? [i'm still on 10 because 11 won't run on my laptop </3]
      - VerifiedReports 7mo ago
        Yes. It's an absolute mess.
        p-t 7mo ago
        God, i finally understand why people hate on windows xD
- perching_aix 7mo ago
  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.
pjc50 7mo ago
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.
joe_mamba 7mo ago
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.
- pjc50 7mo ago
  https://github.com/alexfreud/winamp 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.
- userbinator 7mo ago
  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.
- panxyh 7mo ago
  Yes, of course they were smarter.
- kulahan 7mo ago
  Software seems to have quality and capability as diametrically opposed attributes.
- asveikau 7mo ago
  > 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)
  - blub 7mo ago
    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.
ojeda 7mo ago
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 https://github.com/microsoft/windows-rs
- steve1977 7mo ago
  I just had a look at two examples from that windows-rs repo. https://crates.io/crates/windows-sys https://crates.io/crates/windows-sys https://crates.io/crates/windows 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)
  - poly2it 7mo ago
    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.
  - maleldil 7mo ago
    > 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.
  - LeFantome 7mo ago
    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++.
Lorkki 7mo ago
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?
kelnos 7mo ago
>> 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.)
apatheticonion 7mo ago
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.
- philistine 7mo ago
  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.
  - eru 7mo ago
    > 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..
  - steve1977 7mo ago
    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.
    - marpstar 7mo ago
      MyLifeOrganized was the biggest thing I gave up when I switched to Mac in 2013. Still miss it -- nothing else (Omnifocus, Things, outliners, etc) has been as effective as a system for me. They've been talking about a potential Mac app for year, I'm on the waiting list, but I've given up hope that it'll ever come. Even if it does, I doubt it'll be as good as it is on Windows.
SergeAx 7mo ago
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 https://github.com/sergeax/stamputty
throwaway58670 7mo ago
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++.
1970-01-01 7mo ago
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?

feznyng 7mo ago

How do you make your win32 app look good to the average person?

themafia 7mo ago
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.
- feznyng 7mo ago
  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.
  - rkagerer 7mo ago
    It's funny, the "modern" look has become a countersignal for me. If the app looks like a webpage, I instinctively don't want it. Not because of aesthetics, but simply because I've come to associate that style of appearance with a lack of (or awkward) keyboard shortcuts, featuresets dumbed down to a level appropriate for chimps, various nags injecting friction against getting work done (ads, feature tours, logins, update reminders, etc) and laggy, resource-squandering performance thanks to some kind of bloated rendering framework like Electron with multiple V8 hosting processes sprawled across chrome.exe instances or whatever. Case in point, the Dropbox Simplified Desktop App was a huge improvement for me. It nails just about everything I ever needed their app to do, and removes all the user-hostile fluff I never asked for. Similarly, I found Windows 11 Enterprise IoT LTSC to offer an improved desktop experience compared to traditional Windows, thanks to its exclusion of a lot of the cruft Microsoft otherwise shoves down the throats of users who, as far as I can tell from frank discussions with many of them, likewise actively don't want. I'm not saying your desire to make your app look polished means it's crap, but beauty is in the eye of the beholder. Just like fashion, I wouldn't be surprised if we see a shift in the aesthetics trend as more people discover a retro feel sometimes signals a better user experience.
  - nananana9 7mo ago
    Programmers and designers thinking the average person is a moron is one of the two reasons almost no good software is writren today.
    - SoftTalker 7mo ago
      What's the other reason?
      - nananana9 7mo ago
        That most programmers are not that great at programming, and wouldn't be able to produce high quality software even if that was their stated goal.
userbinator 7mo ago
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.
- deleted 7mo ago
  [deleted]
- lelandfe 7mo ago
  There's a pretty simple settings window: https://github.com/domenic/display-blackout?tab=readme-ov-file#screenshots https://github.com/domenic/display-blackout?tab=readme-ov-fi... Would that UI be hard to accomplish?
  - bloomca 7mo ago
    You mean conceptually or to match it? Native components are pretty much impossible to match without actually using the native framework which provides them, so you need WinUI/WPF. Win32 provides its own components which are basically Win95 style apps, and you can draw the components using some graphics APIs by yourself. The whole native development area is a mess exactly because making your own (decent) renderer is a huge undertaking.
    - Onavo 7mo ago
      But you are making false equivalence, the Win32 GUI API is decades out of date from modern UIs. I can use flutter and make a pixel perfect equivalent of the above UI in an hour, with the exact same responsiveness behavior on both windows tablets and desktop, and scales perfectly in high DPI displays. 3 hours if you want the toggle animation timing to be exactly the same. I came from the WinForms world so don't pretend I don't understand Win32 programming. The fault lies with Microsoft for not investing in it more.
alt227 7mo ago
Disable borders and design your app nicely with images to replace standard user input elements.
- VerifiedReports 7mo ago
  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.
  - p-t 7mo ago
    > removal of title bars they did what??? [i'm still on 10 because 11 won't run on my laptop </3]
    - VerifiedReports 7mo ago
      Yes. It's an absolute mess.
      - p-t 7mo ago
        God, i finally understand why people hate on windows xD
perching_aix 7mo ago
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.

pjc50 7mo ago

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.

joe_mamba 7mo ago

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.

pjc50 7mo ago
https://github.com/alexfreud/winamp 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.
userbinator 7mo ago
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.
panxyh 7mo ago
Yes, of course they were smarter.
kulahan 7mo ago
Software seems to have quality and capability as diametrically opposed attributes.
asveikau 7mo ago
> 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)
- blub 7mo ago
  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.

ojeda 7mo ago

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 https://github.com/microsoft/windows-rs

steve1977 7mo ago
I just had a look at two examples from that windows-rs repo. https://crates.io/crates/windows-sys https://crates.io/crates/windows-sys https://crates.io/crates/windows 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)
- poly2it 7mo ago
  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.
- maleldil 7mo ago
  > 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.
- LeFantome 7mo ago
  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++.

Lorkki 7mo ago

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?

kelnos 7mo ago

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

apatheticonion 7mo ago

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.

philistine 7mo ago
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.
- eru 7mo ago
  > 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..
- steve1977 7mo ago
  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.
  - marpstar 7mo ago
    MyLifeOrganized was the biggest thing I gave up when I switched to Mac in 2013. Still miss it -- nothing else (Omnifocus, Things, outliners, etc) has been as effective as a system for me. They've been talking about a potential Mac app for year, I'm on the waiting list, but I've given up hope that it'll ever come. Even if it does, I doubt it'll be as good as it is on Windows.

SergeAx 7mo ago

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 https://github.com/sergeax/stamputty

throwaway58670 7mo ago

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

1970-01-01 7mo ago

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?