[HN Gopher] Windows native app development is a mess
___________________________________________________________________
Windows native app development is a mess
Author : domenicd
Score : 290 points
Date : 2026-03-22 09:57 UTC (13 hours ago)
(HTM) web link (domenic.me)
(TXT) w3m dump (domenic.me)
| ashwinnair99 wrote:
| It has been a mess for 15 years and Microsoft keeps making it
| worse by adding new frameworks without retiring the old ones.
| Win32, WPF, WinUI, MAUI. Nobody knows which one to pick.
| Smalltalker-80 wrote:
| Yes, and the hubris sting-of-death was UWP. They tried to make
| Windows into a mobile OS, severely restricting the alowed
| actions of programs, including strict certification to be able
| to run them (elsewhere). Of course nobody went for this and UWP
| died a quiet death. Recently there are signs that MS is trying
| to go back to making products that users actualle want (Win11
| reverts). We'll see...
| pdpi wrote:
| > (Win11 reverts).
|
| I must've missed that one. What did they revert?
| lpcvoid wrote:
| It doesn't matter - what Microslop says and what they do
| are traditionally very distinct things.
|
| But in case you want to read yourself:
| https://blogs.windows.com/windows-insider/2026/03/20/our-
| com...
| Traubenfuchs wrote:
| "File explorer launch experience" -hard to tell if this
| is satire...
| Smalltalker-80 wrote:
| I did mean these, very recent promises (vaporware at this
| moment), without satire.
| https://blogs.windows.com/windows-insider/2026/03/20/our-
| com...
| anonymars wrote:
| > They tried to make Windows into a mobile OS, severely
| restricting the alowed actions of program
|
| They already had Silverlight! For Windows Phone 7. Then they
| killed that off too and expected the "plethora" of WP7 apps
| to be rebuilt for WP8 (requiring the beloved Windows 8
| desktop OS for this task). Then they _again_ expected
| developers to throw _that_ away in favor of UWP for Windows
| 10, which unified the desktop and phone OSes. By then it was
| too late.
|
| Old apps still ran on the newer OSes but the SDKs became
| dead-ends.
| ack_complete wrote:
| It's hard to describe how uselessly restrictive the UWP model
| was when they originally introduced it as "Metro-style apps"
| in Windows 8. Among the things it officially did not support
| included:
|
| - Multiple monitors - Non-full screen views - Sideloading
| outside of the Store - Offline installation - Explicit
| threads - thread pool only - Aligned memory allocation -
| malloc only - Any C++ compiler other than MSVC - Support for
| any version of Windows other than Windows 8 - Running apps as
| administrator - Running more than one instance of an app at a
| time - Runtime shader compilation
|
| If any ONE of these things was a blocker, you could not write
| a Metro style app. And yet Microsoft pushed this extremely
| hard -- including almost completely ending any maintenance of
| Win32 APIs. And despite the many relaxations and extensions,
| UWP is still largely useless today, and now even itself seems
| to be going into maintenance mode. All of which has done a
| lot of damage to the state of Windows desktop platform
| development.
|
| As an example of how bizarre UWP is, for some reason every
| time they published a list of new APIs added to it, they
| converted the list of API identifiers to lowercase in the
| documentation:
|
| https://learn.microsoft.com/en-us/windows/uwp/whats-
| new/wind...
|
| It's relatively insignificant, but... why? Just one of many
| things that showed how immature UWP was.
| mschuster91 wrote:
| > without retiring the old ones
|
| They'd lose too much enterprise software that's not being
| maintained any longer but still is business critical.
|
| You can still run most programs from the Windows 95 era
| unmodified on a modern Windows 11 machine and _a lot_ of things
| is relying on that under the hood.
| hrmtst93837 wrote:
| Picking a stack for native Windows UI is like rolling dice,
| except sometimes you get bitten by COM for fun. If you care at
| all about backwards compatibility or deploying outside the MS
| Store you basically end up circling back to Win32 APIs much as
| the frameworks would love for you to pretend otherwise.
| Ironically, the 'official' docs now reads like a half-hearted
| apology for the last decade of churn.
| int_19h wrote:
| You don't have to go all the way back to Win32; anything from
| the pre-WinRT era is fine. MFC, WinForms, WPF are all still
| supported and updated.
| wolvoleo wrote:
| > And from what I can tell, neither are most developers. The
| Hacker News commentariat loves to bemoan the death of native
| apps. But given what a mess the Windows app platform is, I'll
| pick the web stack any day, with Electron or Tauri to bridge down
| to the relevant Win32 APIs for OS integration.
|
| Well yes as a user I prefer native apps for their performance.
| It's clearly a mess to develop native apps as the article shows.
| But as a user I don't see that problem. I do see ever worsening
| apps though. Like the total mess that is new outlook and teams.
| aaomidi wrote:
| When Microsoft themselves use electron to develop apps what
| expectations can we have on other devs?
| Sindisil wrote:
| To do better?
|
| It's demonstrably possible. And further, why does what some
| portion of Microsoft, a huge, multi-headed beast, does
| qualify as the bar for what is reasonable for users to
| expect?
| aaomidi wrote:
| As a user Microsoft is windows and windows is Microsoft.
|
| If doing native apps was realistic then I'd expect windows,
| Microsoft, etc to also do them.
| ethin wrote:
| This, and add to that the fact that web apps make it
| trivial for the dev to just randomly change the GUI out
| from under me without my consent or ability to prevent it,
| and, well, wonder why I and so many others dislike them? I
| want to be able to refuse app updates, thank you very much.
| lenkite wrote:
| A question - _Which_ portion of Microsoft, the multi-headed
| beast develops pure-native apps now ? Even the Windows 11
| Settings app is Javascript.
|
| The multi-headed beast has been assimilated by web-tech.
| They can't code GUI C++ no more - except their
| compiler/graphics team. And even the latter are dying.
| contextfree wrote:
| There are like three settings pages that use JavaScript
| and React Native, the vast majority of Settings is C++
| and XAML/WinUI2
| kelvinjps10 wrote:
| but that was already developed, all new development it's
| going with web based at microsoft
| domenicd wrote:
| Id be interested in a source for both this and the
| parent's comment. How do we know which settings pages use
| which tech? Have people been decompiling them?
| DANmode wrote:
| To decide what tools are the right job for each project,
|
| same expectation as always.
|
| So many "let's race-to-the-bottom along with the authority"
| comments on HN lately.
|
| Dude: no! =]
| wolvoleo wrote:
| Microsoft has always stood for mediocre quality software so
| that's no surprise.
|
| Also, they stopped caring about Windows because they want
| recurring service revenue. Making Windows a subscription
| service for consumers would outrage the users (even though
| they kinda already do this for business with Microsoft 365).
| So the consumer market is just viewed as a billboard for M365
| and Copilot. So everything you see there is just lowball
| effort, even worse than their normal quality.
| bigstrat2003 wrote:
| Considering people are leaving Windows in part because
| Microsoft is shoving web slop into it, perhaps other devs
| should learn the lesson that it's not acceptable to use web
| frameworks on the desktop.
| hu3 wrote:
| Speaking about Electron, for my own little tools I have been
| using TypeScript+Bun with Electrobun.
|
| https://github.com/blackboardsh/electrobun
| runjake wrote:
| This is neat! I clicked through about 10 app examples on that
| page and _none_ of them had a screenshot of the app!
|
| It's a grave sin to have an app repo without a screenshot in
| the main README.md.
|
| Note: Yes, I know that electrobun itself has videos on the
| README.md
| NetMageSCW wrote:
| That's ironic given that the new Outlook and Teams are a mess
| because they are web apps instead of native apps.
|
| Web apps cause have lots of trouble emulating proper native
| look and feel and often have wierd issues with things like
| consistent focus and keystroke navigation. They have all the
| dumb issues of Java apps with no improvements beyond not being
| Java and are slower and more memory heavy to boot!
| intrasight wrote:
| "So when I went to work on my app, I was astonished to find that
| twenty years after the release of WPF, the boilerplate had barely
| changed."
|
| Such is the benefit and the curse, I guess, of having the Windows
| API being locked in the distant past for backwards compatibility.
|
| I've always been surprised that Microsoft didn't do a full
| operating system refactor and provide a compatibility layer for
| running old binaries. Perhaps they figure it would be better to
| just transition everything to software as a service using web
| tech? But I just don't see how that strategy is gonna work long-
| term.
| fsloth wrote:
| "I've always been surprised that Microsoft didn't do a full
| operating system refactor and provide a compatibility layer for
| running old binaries"
|
| Just keeping a legacy system in working order is different
| skillset than writing a new system from scratch.
|
| So you need a new team. Nothing from Windows maintenance
| transfers.
|
| Maybe would require hiring someone who knows how to design an
| OS.
|
| It would be a major undertaking, needing protection by CEO (and
| if it would not succeed CEO would loose a lot of prestige).
|
| I'm not saying MS does not have the existing talent base. I
| don't _know_.
|
| But I've been inside a house maintaining a monstrous legacy
| codebase.
|
| I can tell you - it requires surprisingly little deep
| understanding just to keep an existing system going.
| hypercube33 wrote:
| I mean technically they did with Windows on NT and again with
| Windows on Windows 64. Vista was also a huge redesign from
| the 1990s NT to a lot of the new technologies they'd made in
| Longhorn.
| mwkaufma wrote:
| They DID such a refactor for Win NT under David Cutler. Even in
| that comparatively simpler time it was a huge undertaking, and
| required all-hands-on-deck management that doesn't exist
| anywhere in tech anymore, let alone at today's Microsoft.
| delduca wrote:
| Best framework for this is Qt.
| madduci wrote:
| MFC is rock solid too
| adzm wrote:
| WTL and ATL also, especially if you need to do com stuff
| pjmlp wrote:
| You will need it, because since Windows Vista, most new
| APIs are COM based, as they redid Longhorn ideas in C++
| instead of .NET, and WinRT also builds upon it.
|
| Classical Win32 C API surface, with some exceptions, is
| mostly stuck in Windows XP view of the world.
| jordand wrote:
| Yeah for my work, legacy Win32/WinForms/WPF codebases tools are
| kept maintained as-is, but new tools are usually written in
| PySide6 (QtWidgets or QtQuick) and it's worked out really well
| (other than bundling/distribution being tricky for big apps)
| anthk wrote:
| And Lazarus/FPC.
| hliyan wrote:
| I've recently discovered FLTK:
| https://www.fltk.org/doc-1.4/intro.html
|
| Haven't used Qt in a while, but at first glance, seems simpler:
| https://github.com/fltk/fltk/blob/master/examples/menubar-ad...
| lazypenguin wrote:
| FLTK is great at being fast and light, that's about it. It's
| kind of cumbersome to use but honestly does what it says on
| the tin. Highly recommend for smaller use cases but can't
| imagine using on a large project. I used the rust bindings
| which are well maintained.
| ozim wrote:
| That is why everyone even Microsoft themselves does Electron.
|
| Running with html/css/js has benefits it really is open and free
| development based on international standards and not locked into
| any single big tech.
| ToucanLoucan wrote:
| Clown shit. "We're made our own OS a nightmare to build on so
| we're gonna use JavaScript powered pseudo-VMs and make
| everything take 2 gigs of ram minimum"
| pier25 wrote:
| Isn't Microsoft also using React native for desktop stuff?
| Boxxed wrote:
| I don't know, I think it's pretty embarrassing that Teams is an
| electron (or whatever) app. The plot on native has been lost
| _so badly_ that even the fucking company that makes the OS
| doesn 't want to deal with it.
| anthk wrote:
| NPM it's the bigger turd happened ever, slow and bloated. And
| JS today amounts the biggest enforced propietary loading method
| of existence in almost every web page.
|
| Open? You wish.
|
| >and not locked into any single big tech.
|
| DRM and propietary cody tells me otherwise.
| IlikeMadison wrote:
| Electron is the worst thing that happened to quality software.
| I spoke to two HR guys last year at the company I'm working at
| and they told me they ditch every single resume mentioning "web
| technologies" in them. Funny part is when they also told me
| these "bad" resumes are for the vast majority H1B wannabees.
| debugnik wrote:
| What's so funny about that? Most electron turds I deal with
| are American in the first place, they must be trying to
| appeal to you.
| ToucanLoucan wrote:
| Second. I wouldn't say we ditch resumes on that basis, but
| ultimately, we're a native outfit only. You can be the best
| damn app developer on Earth but if all you've ever used is
| Electron, well, I can't use you.
| NetMageSCW wrote:
| Say what you will about Apple, they at least still think it's
| important to support and do native development, especially for
| their OS. Microsoft might as well have bought webOS as their
| new Windows replacement and admitted they've given up on native
| apps.
| userbinator wrote:
| Do original Macintosh binaries still run on the latest macOS?
| I haven't looked much at the situation on that side but I
| believe Apple has no equivalent to the Win32 API.
| cv5005 wrote:
| 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?
| LAC-Tech wrote:
| Winforms?
|
| lol at them still bekng the best option. so much wasted effort
| trying to replace them
| pjc50 wrote:
| 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.
| HauntingPin wrote:
| 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.
| bob1029 wrote:
| 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%20
| sta...
| pjmlp wrote:
| 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...
| Quarrelsome wrote:
| 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".
| runjake wrote:
| It's been a while since I've touched it, but IIRC they made
| WinForms play with Hi-DPI nicely.
| pjmlp wrote:
| 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.
| ack_complete wrote:
| 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.
| Quarrelsome wrote:
| 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.
| jordand wrote:
| 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.
| cv5005 wrote:
| 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'.
| jordand wrote:
| 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
| mschuster91 wrote:
| Doesn't WINE have pretty decent documentation by now from all
| the reverse engineering?
| sourcegrift wrote:
| Wine cannot even install office 2014. It's not really as
| food as some claim sadly.
| anthk wrote:
| Lutris can up to 2016.
| jordand wrote:
| 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
| Dwedit wrote:
| 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.
| raw_anon_1111 wrote:
| That sounds like the same ugly hack that caused programs
| not to be "32 bit clean" back in the day for Macs
| rwmj wrote:
| 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.
| dcrazy wrote:
| This is how pointer authentication codes work on Arm64.
| projektfu wrote:
| It's all good if you have 128kb ram but they should have
| had a plan to escape it from day one.
| ack_complete wrote:
| One difference is that the Mac OS itself was not
| initially 32-bit clean, with the top byte being used by
| the Memory Manager.
| criddell wrote:
| 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.
| NetMageSCW wrote:
| Having to use macros for literal strings in your code is
| just incredibly stupid of Microsoft and/or C++.
| gzread wrote:
| 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.
| projektfu wrote:
| 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.
| lucianbr wrote:
| How does it look? I mean, what do the widgets look like?
| cv5005 wrote:
| This was an MFC project, so your old standard win32 common
| controls that looks the same since 98 or so.
| samiv wrote:
| 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.
| mcswell wrote:
| Repeat after me: New! Fresh! Clean!
| raw_anon_1111 wrote:
| 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)
| userbinator wrote:
| Better to have known unknowns, than unknown unknowns.
| sethhochberg wrote:
| 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).
| user____name wrote:
| 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.
| cosmic_cheese wrote:
| 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.
| 762236 wrote:
| This is such a wonderfully beneficial comment to the HN
| community. It should get an award.
| dgxyz wrote:
| 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.
| lylejantzi3rd wrote:
| But, why? It's been 30 years. You'd think somebody would
| have figured out how to make a decent GUI toolkit or
| framework.
| dgxyz wrote:
| We just built layers of shit over the ones we have.
| lenkite wrote:
| 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.
| NetMageSCW wrote:
| 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.
| int_19h wrote:
| 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.
| Marsymars wrote:
| 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.
| exceptione wrote:
| AvaloniaUI + MVVM toolkit.
| rwmj wrote:
| 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.
| bigfatkitten wrote:
| Tcl/Tk was also popular in certain niche products, like
| in RF test equipment.
| rwmj wrote:
| It's still quite big in EDA (electronic design software).
| steve1977 wrote:
| 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.
| kageroumado wrote:
| 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.
| dcrazy wrote:
| 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.
| steve1977 wrote:
| And this already worked in OPENSTEP, like 30 years ago.
| paulddraper wrote:
| Programming with GUIs?
| gzread wrote:
| 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.
| bigyabai wrote:
| Visual Studio and XCode are way, way overkill for most
| software and eventually constraining for bigger projects
| too.
| Marsymars wrote:
| 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.
| dcrazy wrote:
| Yes, generations of Mac and Windows programmers have used
| GUIs to create their GUIs. Visual Basic, MFC + App
| Studio, .NET + WinForms, Interface Builder...
| markus_zhang wrote:
| 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.
| mayoff wrote:
| How to add a button in SwiftUI:
| Button("Click Me") { buttonWasClicked() }
| StilesCrisis wrote:
| 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.
| raw_anon_1111 wrote:
| And the 12 different ways to define a string depending on which
| API you call
| tsss wrote:
| 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.
| troupo wrote:
| Most apps at the time managed that quite successfully. IIRC
| Adobe Photoshop was an MFC app. There was no other API but
| Win32 API.
| QuadmasterXLII wrote:
| Spotify would be remarkably improved if it became a simple
| enough gui to be excluded from this conversation.
| pjc50 wrote:
| WinAmp was the win32 music player of choice, once upon a
| time.
| magicalhippo wrote:
| > 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...
| badsectoracula wrote:
| > 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.
| dgxyz wrote:
| 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.
| moomin wrote:
| 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.
| finghin wrote:
| 'Madness is something rare in individuals -- but in groups,
| parties, peoples, and ages, it is the rule' --F. Nietzsche
|
| (tongue in cheek)
| tibbydudeza wrote:
| Same here - our IOT device is a i5 running Windows IOT.
| Recently I switched from C++/Win32 to Golang and walk.
| sys_64738 wrote:
| 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.
| int_19h wrote:
| 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.
| psyclobe wrote:
| But isn't that illegal now? You have to write everything in
| rust according to their cto.
| kelvinjps10 wrote:
| and it would work on linux with wine lol.
| bentt wrote:
| I wonder if Unity (the game engine) actually has a sneaky
| potential here. It's cross platform, fast, and maybe just maybe
| less bloated than carrying around an entire browser like
| Electron?
| v9v wrote:
| I think Godot is a possible contender as well. There are a few
| non-game applications made with it, and they've recently added
| a docs page tailored to non-game application development:
| https://docs.godotengine.org/en/stable/tutorials/ui/creating...
| pier25 wrote:
| Flutter is probably better suited for apps
| netbioserror wrote:
| Speaking from personal experience, Godot has the sneakiest
| potential. It has all the UI components and flexible layout
| containers you could ask for, a signaling system that lets you
| put the methods from less relevant components in the scripts
| for more relevant ones (making for a more compact project), and
| you can also manually compile slim template builds for cleaner
| distribution. There's a future there.
| hofrogs wrote:
| There are already tools made in Godot, including the godot
| editor itself. This page has some of them:
| https://gamefromscratch.com/godot-developed-non-game-
| applica...
| tomcam wrote:
| What's the story for accessibility and non-LTR text boxes?
| jordand wrote:
| Unity has a big runtime that needs to be bundled with it to run
| fsloth wrote:
| Sure but different target market.
|
| CRUD apps are non-trivial.
|
| If Unity were to ship platform native replacement for WPF
| equivalent (hell or even winforms) it would become a really
| enticing app development platform.
| flohofwoe wrote:
| > CRUD apps are non-trivial.
|
| Aren't these pretty much the most trivial UI apps possible?
| E.g. compared to other native apps like Photoshop, Blender,
| Visual Studio or Office, CRUD is mostly just about banging
| together custom UI frontend for a database.
|
| Unity's editor is implemented in its own (old) UI system,
| same with Godot, so in both engines it's possible to create
| 'traditional' non-game UI applications.
| Vedor wrote:
| Not sure about Unity, bot Godot is already used to build tools,
| like Pixelorama (pixel art graphics editor, a bit akin to
| Asesprite), RPG In A Box (game engine targeted for RPG games),
| Bitmapflow (tool to generate in-between animation frames), and
| probably more I don't know about.
|
| Well, if I remember correctly, the Godot editor is written in
| Godot.
| Supermancho wrote:
| Godot is written in C++ It may have some GDScript in there,
| but I don't think so. The sourcecode is available:
| https://github.com/godotengine/godot
| hofrogs wrote:
| The C++ code there (at least in the editor directory)
| initializes and configures godot ui components that the
| editor is made of
| moron4hire wrote:
| Unity's 2D UI stuff is very poorly designed, with lots of edge
| cases where auto-calculated fields can hit a divide-by-zero
| issue and then become unrecoverable because the value is now
| NaN which can't be auto-calculated back to a number.
| irishcoffee wrote:
| Just use Qt. Native, cross-platform, works like a champ.
| NetMageSCW wrote:
| Cross-platform and native never works well.
| irishcoffee wrote:
| You've never used Qt
| hermitcrab wrote:
| Nothing is perfect, but it works well in my experience.
| array_key_first wrote:
| Qt works very well because it's well thought out software.
| There's a lot of really shit solutions out there, but
| basically nothing touches Qt.
| criddell wrote:
| What's the accessibility story like? Do Unity applications work
| well with screen readers?
| lpcvoid wrote:
| Lazarus is crazy good, as is Delphi, if you can afford it.
| wxWidgets is also nice, without the licensing weirdness that is
| Qt.
| steve_taylor wrote:
| Lazarus is probably the easiest way to make a lean and fast
| native Windows app without paying for tooling.
| throwaway2046 wrote:
| wxWidgets is just a wrapper around existing UI libraries; win32
| on Windows, and Gtk/Qt on *nix.
| lpcvoid wrote:
| Yes, as is the VCL that Delphi ships, along with the Lazarus
| component library which bases on Qt or GTK on Linux, and
| Win32 on Windows. It's the same sort of layer.
| anthk wrote:
| Given the size of some Electron software, bundling TCL/Tk with
| IronTCL and TCLLib+TKLib weights 58MB and you can develop your
| own software with it, and that with the source of everything
| included.
|
| And if you set a native theme for TTK in your code (literal two
| lines), your software will stop looking Motif-Industrial, the
| widgets will have the classic Win32 themes. It will look native
| from XP and up.
| whobre wrote:
| Interestingly, no mention of WTL
| domenicd wrote:
| Ahah, I knew I missed one!
|
| I originally had ATL in there, but my proofreading squad
| (Claude and ChatGPT) told me that ATL was a more niche thing
| for COM, and looking at the Wikipedia article I was convinced
| they were right.
|
| But WTL was what I was thinking of---the step between the MFC
| and .NET that I forgot.
| odkeidjwidj wrote:
| > but my proofreading squad (Claude and ChatGPT) told me
|
| With all due respect (seriously): fuck off man
|
| This is why you don't use these stupid fucking tools for this
| int_19h wrote:
| WTL was never a "step between the MFC and .NET" in any
| meaningful sense. It was more like a very lightweight subset
| of MFC+ATL, never officially supported or recommended, just
| something that Microsoft used internally that it decided to
| publish and then community picked up.
| sylens wrote:
| Author raises several good points. Why isn't the latest .NET
| runtime pulled down into Windows 11 devices via Windows Update?
| Why isn't there a better path forward for deployment?
|
| It's another example of how they have completely abandoned any
| attempt at providing a good user experience across their products
| c-linkage wrote:
| There are a few reasons that I can see why they don't integrate
| the latest .net.
|
| First is that the security model changed with .net 5. Next is
| that they subsume Mono/.net core into the foundation of the
| language and this cost them them the ability to support Windows
| native development, specifically anything to do with Win32 API.
|
| If you look at .net 10 and compare that to .net 5 you can see
| that they are trying to reintegrate the Win32 API but now it is
| in the all new Microsoft namespace.
|
| The amount of change is too significant to act as a drop in
| replacement for the original .net framework. Maybe they could
| have gone a side-by-side installation, but the rapid
| development of The NET Framework I think made it too hard to
| tie to an operating system update. They wanted to free it from
| that update cycle of once a year or every two years and allow
| the development to progress rapidly at the cost of having to
| download it and install it each time.
| domenicd wrote:
| Side by side is what I'm asking for. Just like there's
| WebView (IE-based) and WebView2 (Chromium-based, evergreen,
| updated every 4 weeks).
|
| I don't think the rapid development cycle argument holds
| water, when they're shipping a new WebView2 every month.
| jayd16 wrote:
| Windows update is how it used to work and it's terrible. An
| update breaks old apps, or downloads a every single version
| (not feasible). Who would want to run windows update to install
| a new app?
|
| It's just a bad idea. Today we just pack in the DLLs and it
| just works.
| NetMageSCW wrote:
| No one suggesting using Windows Update to install new apps,
| they are suggesting the current .Net framework should be
| elevated to a first class Windows citizen and included with
| Windows installs and updated with Windows Update, and that
| seems like and obvious idea that should have been implemented
| when .Net Core became .Net.
| Rohansi wrote:
| .NET versions are not fully backwards compatible. Would you
| like every Windows install to ship with over ten versions
| of the .NET runtime?
| biorach wrote:
| Yes?
| jitl wrote:
| We would like it to be good. Whichever way to achieve
| goodness - either be backwards compat, or ship all the
| stable versions, I don't care but the current situation
| is silly. Apple gets flack for this and that, but their
| UI toolkit situation is lightyears ahead; you just pick
| the OS version you want to target in your app build
| settings and it will work that way for everyone.
| Rohansi wrote:
| 100 MB per runtime, for everyone, and the majority of
| them are out of support. Is that really the good option?
| Why not the option the author dismissed: a 9 MB AOT-
| compiled executable which doesn't need a separate
| runtime?
| userbinator wrote:
| _An update breaks old apps_
|
| That's something which is MS' problem; they're supposed to be
| the company who is best at backwards compatibility, but
| clearly have strayed from that path.
| moomin wrote:
| There's two versions of .NET. One is "legacy", which is stable
| as anything and bundled with the OS. The other is "Core", that
| only has support for three years and isn't 100% compatible. The
| reason the latest .NET runtime isn't bundled is the above: the
| stable version is bundled.
| Atotalnoob wrote:
| Core is compatible with non deprecated apis.
|
| That's why they had .NET 5im stead of .net core 5
| Rohansi wrote:
| I'm assuming but the versions are not fully backwards
| compatible so you can't just ship the latest version, they
| would need to ship all. There almost ten .NET versions released
| after the one which ships in Windows. And a new version is
| released every year.
|
| The author does mention that .NET does have distribution
| options which don't require the user to install the runtime.
| You can have it package the full runtime with your build,
| either as a bunch of files, a self-extracting executable, or a
| standalone AOT-compiled native executable.
|
| The author mentioned that the AOT-compiled executable is 9 MiB
| which is unacceptable to them. The other options will need even
| larger. Personally I don't see 9 MiB as a big deal especially
| when the author would rather go with Electron which is larger
| at worst (bundled Chromium) and only inefficient at best
| (system WebView).
| samiv wrote:
| Seems to me that really the simplest solution to authors problem
| is to write C++ safely. I mean...this is a trivial utility app.
| If you can't get that right in modern C++ you should probably
| just not even pretend to be a C++ programmer.
| rwmj wrote:
| Just write C++ safely! Why didn't we think of that?
| array_key_first wrote:
| C++ is hard to get safe in complex systems with hard
| performance requirements.
|
| If the system is simple and you don't give a shit about
| performance, it's very very easy to make C++ safe. Just use
| shared_ptr everywhere. Or, throw everything in a vector and
| don't destroy it until the end of the program. Whatever, who
| cares.
| flufluflufluffy wrote:
| Yeah he literally answered his own question and then used a
| random excuse for not going with the option.
| livinglist wrote:
| Still remember the days of writing apps for windows phone using
| c# and XAML. Good old times but no definitely don't wanna go
| back.
| PaulKeeble wrote:
| Most of the desktop applications I have wrote over the years have
| been in other languages like Java and Go as I have wanted them to
| mostly be cross platform. In these cases I have always used the
| Software UI, which in Java is Swing and in Go is Fyne. These are
| usually reasonably fast, don't necessarily look native depending
| on how its themed but ultimately fit the language better than
| trying to bridge to Win32 or GTK/QT.
| NetMageSCW wrote:
| But punish the user so you can develop cheaply and lazily? I'm
| not sure that's a model I would want to follow.
| rwmj wrote:
| This is quite timely as we need to write a simple UI for Windows
| (a few buttons, status, maybe a file menu). The main constraint
| is it must compile to a single binary (.exe) with no dependencies
| such as runtimes, DLLs, languages etc. It also needs to run on
| some older unsupported Windows systems, probably Windows >= 7, 32
| bit.
|
| My first thought was MFC. Basic, fast, well understood.
|
| But then maybe WxWindows so we can cross-compile it (from Linux)
| and use the same UI on other platforms? It could probably be
| compiled statically although I've not tested it.
|
| Or Mono, but that needs a runtime?
|
| Edit: Some comments mention Qt which could also work although how
| large is the runtime? Can it be compiled statically?
| kwanbix wrote:
| Delphi or Lazarus (https://www.lazarus-ide.org) should solve
| it.
| rwmj wrote:
| Nice, I didn't know there was a free software version of
| Delphi nowadays.
| dardeaup wrote:
| With restrictions of course.
| kwanbix wrote:
| If you mean Delphi Community, it has some restrictions, but
| probably 99% works?
|
| If you mean Lazarus, it is fully open source. No
| restrictions but the ones of the software itself.
| Conan_Kudo wrote:
| > Edit: Some comments mention Qt which could also work although
| how large is the runtime? Can it be compiled statically?
|
| You need a commercial license for that, but yes you could. But
| since applications are typically distributed with install
| bundles that put into application-local program files
| directories, it's not super-important as long as you only
| cherry-pick the Qt libraries you need.
| rubymamis wrote:
| This is wrong. There's a misconception that you can't
| statically link your app when using the open-source LGPL
| version of Qt. From my reading of the LGPL license this
| doesn't appear to be the case[1]. The LGPL allows you to
| statically link your app as long as you provide the object
| files and allow users to relink your app with a different
| version of Qt.
|
| I've observed many people spreading this misinformation about
| only being able to dynamically link with the LGPL version of
| Qt. Please stop this.
|
| [1] https://www.gnu.org/licenses/gpl-
| faq.html#LGPLStaticVsDynami...
| Conan_Kudo wrote:
| Yes, that _is_ true, but in practice nobody has ever done
| that. And the material complexity of offering that mode is
| higher than just dynamically linking the library.
|
| Also, modern compilers make this method much harder to use.
| It is much harder to stably relink object files like that
| than to just use the normal dynamic link method.
| Atotalnoob wrote:
| .net will work. Use a weaver (fody) or the modern features to
| roll everything into 1 .exe.
|
| Use self-contained to have everything together.
|
| https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
| lstodd wrote:
| For such a trivial thing I'd just take imgui.
|
| MFC, wx, Qt .. it's all overcomplex pointless bloat for this
| task imo.
| hermitcrab wrote:
| Qt is compiled to a native .exe. It doesn't have a runtime. To
| give you a rough idea of size, I have 3 GUI application written
| using Qt/C++. The installers are 72 MB, 69 MB and 32 MB. The
| first 2 include a significant amount of documentation. I could
| probably get them a bit smaller if I really needed to.
| userbinator wrote:
| Pure Win32 will do exactly what you want. Single tiny .exe that
| works from Win95 to 11. Even Linux with WINE.
|
| Get started learning here:
| https://news.ycombinator.com/item?id=21459616
| int_19h wrote:
| For what you describe, .NET + WinForms or WPF will work just
| fine. These days it can built self-contained executables,
| although they won't be small (but then again, when many
| websites have multiple megabytes of JS...). Or you can target
| .NET 4.8 - for something this simple I doubt there'd be much
| difference but then you can ship an .exe that measures in
| kilobytes, and the runtime is included with every version of
| Windows going back 10 years.
| LocalH wrote:
| WinForms forever :evil:
| GeoAtreides wrote:
| come back home Delphi 7, all is forgiven
| dardeaup wrote:
| It seems that peak native Windows dev tools were Delphi 7 and
| VB6. It's a tragedy that something at least as good as VB6 is
| not still developed and supported by Microsoft.
| rcleveng wrote:
| There's nothing as good as VB6 that's developed and supported
| by *anyone*. It's not a Microsoft only phenomena.
|
| I think programmers started wanting "real" languages (notice
| the quotes), and henceforth got more complexity and things
| take longer, although with GenAI, we may be back to the "draw
| as screen and do this" that we were with VB6. Just now the
| source generated should be considered the object code, and
| the prompt is the new source (at least for those types of
| apps)
| NetMageSCW wrote:
| I think WinForms with C# or VB is as good, if perhaps not as
| fun or approachable.
| int_19h wrote:
| I'm not sure how you define "native" here. If you mean native
| widgets then WinForms does what you want, is still fully
| supported, works on modern .NET versions, and Visual Studio
| still has all the GUI designers etc. WinForms is very
| obviously a calque of VCL, as well, so it can do everything
| Delphi did, but better.
|
| If you mean native _code_ then VB6 doesn 't belong in this
| category (even if you compiled it to a standalone .exe it was
| still effectively bytecode).
| ocdtrekkie wrote:
| I write .NET Framework 4.8 apps. And I will until .NET has an
| actual support lifetime. 4.8 will still be supported and
| receiving security updates in ten years, .NET 10 will be gone in
| 2.
|
| Hobby projects should not be built on a platform that is
| constantly changing underneath.
| Marsymars wrote:
| My company is moving our main LOB app to .NET 10 in the near
| future. It's taken a while but has gotten to the point where
| .NET 10 has pretty much caught up to .NET Framework for feature
| support, and our take is that the cross-platform support,
| performance gains and newer C# versions are worth more than the
| stability of .NET Framework.
|
| And the gap's going to keep growing - doing the upgrade now
| means future upgrades can be more frequent and incremental,
| rather than trying to move 4.8 to .NET 20 in a decade.
| pjmlp wrote:
| Unfortunely I have reduced my use of .NET, because some of
| the partner products that we use, or customers that were into
| .NET, took the opportunity for going into another technology
| stack.
|
| Basically the kind of customers that were affected by the
| breaking changes, between Framework and Core, decided to keep
| the old stuff running in Framework, and consider other
| alternatives going forward.
|
| Not sure how much these kind of customers matter to the .NET
| team's upper management in customer acquisition, but they
| surely lost a few along the way.
|
| And now there is even CoPilot based migration tooling on VS
| 2026, because most likely there aren't that few that are
| still chugging along with Framework.
| ocdtrekkie wrote:
| If .NET had a desktop UI for Linux it might be worth it for
| me, but we haven't gotten there yet somehow.
| Marsymars wrote:
| Yeah we don't have any plans on moving our WPF app to
| Linux, but the rest of our stack (job scheduler, ASP.NET
| service, web APIs, etc.) all has real potential to get off
| of Windows.
| qayxc wrote:
| But there are libraries that do that, e.g.
| https://avaloniaui.net
| mellosouls wrote:
| Really nice article, thanks - yes I found the same myself
| recently when trying to write a trivial (I thought) Windows app.
|
| I first investigated the Windows native options and was pretty
| bamboozled; I wanted to use the "mainstream" "up to date" option
| (presumably c# and some framework) but as TFA describes, it
| wasn't at all clear which that was.
|
| I ended up doing it in python with pyqt then finding out a clean
| deployment was a pain, so revisited the .Net options and
| remembered why I'd discarded them in the first place...
|
| It is indeed a complete mess (at least coming in anew) and a very
| strange situation for the world's main desktop environment to be
| in.
| p0w3n3d wrote:
| It's always about the abstractions which try to cover the
| underlying mechanisms but not always can do it. The same with any
| programming, like named pipes for example. However I need to tell
| you that
|
| 1. Wow you have great knowledge of windows. Congratulations
|
| 2. Boy windows API is a mess.
| on_the_train wrote:
| All my work experience with guis was mfc. And all modernizations
| were web based. The in betweens are usually not considered
| worthwhile.
|
| But imgui is a breeze of fresh air for internal stuff
| jasonjei wrote:
| It's been a long time since I had to touch Windows development.
| If I had to do it over again, I would use React Native for
| Windows UI where possible and low-level Win32-React Native module
| bridges for user space code.
|
| The last time I had to do Windows development was about 15 years
| ago. I used a library called WTL (I think a couple comments here
| mention it). I couldn't use any of the newer stuff that Windows
| 8-10 were pushing because it needed backward compatibility. It
| seemed way less bloated than MFC, but not as annoying to use as
| ATL or rawdogging Win32 APIs.
|
| Ironically, I was developing a Win32 app to build a cloud bridge
| to a Rails app (talking to Quickbooks COM API which was hell on
| Earth, with XML and XML definitions) on Mac, using VMware on Mac
| to talk to Quickbooks Windows. I was so annoyed with Win32
| development I used the Chrome Embedded Framework library to build
| the UI for the Win32 app so I wouldn't have to wrestle WTL for UI
| and just have browser-based views to drive UI.
|
| I think it was very tempting to drop C/C++ development for .NET
| code, but I didn't want to drop off user adoption by requesting
| users to download a huge .NET runtime if their computer didn't
| already have it.
|
| This was when I was building Levion, a Quickbooks Windows to
| Cloud Rails app...
| apankrat wrote:
| Let me chime in and say that plain Win32 API is a perfectly
| viable option _if_ you are using C++ (or another "OO" language)
| and _if_ you are willing to sink a couple of weeks into writing
| your own MFC-like wrapper.
|
| Clearly this is not an option for those who are just starting up
| with Windows GUI work, but with little experience it is really a
| matter of 2-3 weeks of ground work and then you have full control
| over all nuances of the UI, yours to extend and mend as you wish.
|
| If there's one thing that Microsoft is really good at, it's
| ensuring deep backward compatibility. So anything that's based on
| Win32 API is going to be stable. If it works now, it will work
| later.
|
| I have some examples from 10+ years of development updates
| accumulated here - https://bvckup2.com/wip
| domenicd wrote:
| Judging from the screenshots, that doesn't produce Windows 11
| style UIs, right? I.e. it contributes to the problem exploree
| at https://ntdotdev.wordpress.com/2023/01/01/state-of-the-
| windo...
| apankrat wrote:
| Screenshots are made on Windows 8.1 box, the windows chrome
| comes from there.
|
| Plus the whole thing is meant to work on ancient Windows
| versions (like, Vista and WS2008 ancient), so that ultimately
| defines the minimal common UI denominator.
| jwagenet wrote:
| Maybe I grew up with Windows so the older uis don't phase me,
| but I find these sort of complaints rich considering
| differences between gtk, qt, etc in Linux userland. The
| average Windows user might stumble on an aero dialog, which
| is arguably less jarring in win11 than og metro.
| layer8 wrote:
| Many would consider that a positive.
| airstrike wrote:
| Jesus, that's way worse than I expected before clicking
| pkphilip wrote:
| Why not just use C++ Builder or Delphi?
| gzread wrote:
| Presumably because they don't support C++23
| nslsm wrote:
| I don't want to be _that_ person, but if you can think of a
| decent API for your MFC-style wrapper, an AI should be able to
| write a decent implementation for you.
| AnotherGoodName wrote:
| Agreed. In fact this supports the GPs point about using the
| rawest form of GUI manipulation.
|
| For years we loaded up libraries and abstractions to minimize
| boilerplate. These hid the actual underlying mechanisms and
| often made specific customisations harder to do since you
| were taken away from the raw functionality.
|
| These days AI is extremely good at writing boilerplate and in
| my opinion explicitly typed out boilerplate code is much
| easier to reason about than a library that abstracts things
| away to a one line annotation or similar.
|
| A good example is that i've recently been leaning back to the
| raw Android apis for things like recyclerviews etc. It used
| to be 10+ files to changed to create an efficient scrolling
| view on Android with various resources and adapters required.
| So a whole bunch of libraries came out to try to abstract the
| complexity away. You know what though? I don't care about
| that anymore. I'm going back to the raw GUI APIs where
| possible because it's so explicit and clear even if it's 10x
| more code.
| ack_complete wrote:
| The main thing that's hard going down this route is dark mode
| support. The Win32 USER and common controls just don't not
| support dark mode, but are actively hostile to it due to the
| amount of hardcoded light colors and backgrounds in the system.
| All of the system colors are light regardless of the dark/light
| system setting, highlights are hardcoded to light blue,
| disabled controls use a hardcoded color, half of the window
| messages for changing control colors are silently ignored with
| theming is enabled. Menus are among the more difficult to deal
| with as they require extensive owner draw.
|
| On top of this, there are a small handful of system UIs that do
| support dark mode and make your program look inconsistent with
| dark mode regardless. Message boxes will switch to dark mode,
| and so will file dialogs -- which is a problem if you've used
| the Vista-style customization, as any syslinks will appear in a
| color of blue that's hard to read against the dark mode
| background.
| gzread wrote:
| First, dark mode is for people who set their screen
| brightness too high.
|
| Second, win32 is designed with the ability to change all the
| default colors and you used to be able to do this by right
| clicking the desktop and selecting "properties". If dark mode
| doesn't follow this - just another symptom of Microsoft's
| siloing incompetence. The team that wrote dark mode may not
| have been aware that this feature existed because parts of
| the platform are so disconnected from other parts.
| ack_complete wrote:
| Dark mode for apps is a setting in the OS and a general
| expectation now, it's suboptimal to ship a new UI that
| doesn't support it. And, again, Win32 message boxes in your
| program will switch to dark mode whether you want them to
| or not.
|
| Win32 controls ignoring system colors goes much farther
| back than dark mode being introduced in Windows 10. The
| theming engine that broke a lot of that functionality was
| introduced in Windows XP. Beyond that, there were always a
| few hardcoded colors like disabled gray text going back to
| Windows 95.
|
| Dark mode ignoring Win32 system colors is not incompetence.
| It was _intentional_. Dark mode was introduced by the UWP
| side, which intentionally did not extend it to Win32. To
| this day, there is not even a Win32 API for desktop apps to
| query whether dark mode is even enabled. The official
| recommendation is to compute the luminance of the UWP
| foreground color setting:
|
| https://learn.microsoft.com/en-
| us/windows/apps/desktop/moder...
| ptx wrote:
| But they had dark themes for the XP theming engine, e.g.
| the Zune theme, didn't they? They could make the dark
| mode switch to a dark theme for XP-style themed controls
| and configure dark colors for the Win32 system colors.
| bigstrat2003 wrote:
| Only a very small minority of users actually care about
| dark mode. It is not a general expectation for software,
| as loud as those users may be on forums like this one.
| jitl wrote:
| On Apple platforms is very uncommon to find apps that
| only support light mode. The only one on my phone is the
| app for my old Chinese robot vacuum.
| localuser13 wrote:
| And how do you know this? I decided to check myself,
| looked for dark mode statistics on android, and:
|
| >Dark mode is used by 81.9% of 2,500 Android users on
| their phones, in apps, and in other situations. 9.9%
| alternate between the light and dark
|
| So it's the other way around. Only a very small minority
| of users actually care about light mode.
| fireflash38 wrote:
| I think android is a big difference here. What about
| excel or Google sheets? Word?
|
| If you're building win32 you're not targeting android.
| Marsymars wrote:
| I'm not sure how much Android use generalizes - I prefer
| light mode, but I'll use dark mode for the battery
| savings on portable devices with OLED screens.
| userbinator wrote:
| _Dark mode ignoring Win32 system colors is not
| incompetence. It was _intentional_._
|
| Intentional malice, in other words. A stupid attempt at
| pushing UWP.
| lwkl wrote:
| It is not. I have some issues with my eyesight and dark
| mode makes it easier to use a computer in some lighting
| conditions. So for me dark mode is an accessibility
| feature. And yes you could use the ugly recolor feature
| windows has but dark mode does the same thing and looks
| better most of the time cause a UI designer actually looked
| at it.
| cosmic_cheese wrote:
| > First, dark mode is for people who set their screen
| brightness too high.
|
| Not at all. It became popular mainly because as part of the
| spread of the flat UI epidemic, the previously non-optional
| "light mode" OS UI themes all shifted away from midtone
| colors to blinding stark whites. This meant that monitor
| brightness settings that had previously been comfortable
| suddenly weren't.
|
| On top of this, modern flat UI light mode themes
| consistently have poorer contrast and delineation than
| their dark mode counterparts, because higher contrast with
| darker grays makes flat white UI themes appear "dirty". So
| even if the brightness isn't an issue, your eyes have fewer
| visual cues to guide them.
|
| Aside from that, on IPS panel monitors lowering brightness
| past a certain point also greatly lowers color vividness
| which looks bad, which is why some of us like to keep it
| maybe not maxed but a bit higher than is comfortable with
| light mode.
| shmerl wrote:
| _> If it works now, it will work later._
|
| Wine is better at it than Windows itself. Especially for really
| old programs.
| ww520 wrote:
| The last time I built a native Windows app years ago, I used
| WTL 3.0. It's a light weight wrapper on the native Win32 API,
| lighter than MFC. It took out the unpleasantness of working
| directly on Win32 API and wrapped it in a simple OO framework.
| It had access to all features of Win32. It could produce
| runtime binary in dozens of K, instead of MB or GB.
|
| Microsoft released it open source later on. Looking at the
| repository, looks like it has been kept up and maintained, up
| to version 10 now.
| cachius wrote:
| GitHub mirror of the sourceforge repo:
| https://github.com/Win32-WTL/WTL
|
| _WTL delivers very small and efficient code, very close in
| size and speed to SDK programs, while presenting a more
| logical, object oriented model to a programmer._
| MomsAVoxell wrote:
| I just use JUCE. It solves all the problems I need solved on
| Windows and doesn't lock me into anything. More and more, if its
| not cross platform C++, it just doesn't make any sense to invest
| in it. This is getting more relevant as the years go by, alas.
| NetMageSCW wrote:
| Given OS windows shares, if you are writing desktop, cross
| platform makes no sense for most apps.
| iamcalledrob wrote:
| The author is right, it's really such a mess.
|
| The lessons I've learnt building and shipping a few a Windows
| apps at scale are basically:
|
| (1) Learn Win32 and use those ancient APIs if possible, they're
| extraordinarily stable and you'll probably need to reach for them
| anyway. They're not that scary.
|
| (2) Don't use any Microsoft-owned UI toolkit, you'll get burnt.
| Literally anything is better. Ideally choose a toolkit that
| doesn't prevent layering in Win32 tweaks on top, otherwise you'll
| end up hitting cases the toolkit developers didn't think of and
| you can't fix. You're going to need a custom WindowProc
| eventually. You need to have access to the underlying Win32
| window lifecycle and handles.
| somenameforme wrote:
| > "(2) Don't use any Microsoft-owned UI toolkit, you'll get
| burnt"
|
| This is 100% true for all of their techs produced within the
| past ~20 years, but WPF and Winforms are extremely stable with
| no real issues.
|
| It's so weird too because most of everything they've done in
| the past 20 years has basically just been incomplete remixes of
| WPF. If they just stuck with WPF and extended it onward,
| something like a UI toolkit equivalent of C#, it would 100% be
| the gold standard for Windows development today, and perhaps
| even UI development in general if they open source/standarded
| it.
| beagle3 wrote:
| Ahhm. At previous $DAYJOB, I inherited a WPF app written in
| 2012; I stumbled upon several WONTFIX bugs through the years
| - mostly having to do with shared memory bitmaps, having to
| manually call GC at times, and a host of other things.
|
| Stable, but many issues. Stay away if you value your sanity
| and do anything nontrivial.
| projektfu wrote:
| When they announced UWP I was just starting a new side
| project and I thought, let's check it out. I was hoping it
| would basically bring WPF into first class citizen territory.
| Instead, they made them needlessly incompatible. Like writing
| for both NeXT and MacOS, but on the same platform. I got
| discouraged right away and have really never done any
| significant Windows work since, which turned out to be a
| great move for my sanity.
| kelvinjps10 wrote:
| the should just have updated wpf with their newer widgets and
| just continue to improve it and even make it cross platform.
| (basically what avalonia is doing)
| ilovecake1984 wrote:
| There seems a lot of conflation between GUI frameworks and
| interacting with the OS in this article.
| AyanamiKaine wrote:
| Because I didnt see it already mentioned. Avalonia[1] and Uno[2]
| for C# are also really great if you want to write windows apps. I
| wrote some in Avalonia that worked incredible nice on Linux and
| Windows.
|
| You dont have to use MVVM or AXML for example Uno allows for C#
| Markup[3] to be used instead or MVUX instead of MVVM.
|
| I personally hate MVVM and AXML but you are not forced to use
| them.
|
| For Avalonia I dabbled in creating my own replacement[4] for MVVM
| and AXML using Flecs.Net.
|
| In Avalonia I created a tray icon for the trash bin. So I can see
| how big it is and clear/open it with a small menu[5].
|
| Both Avalonia and Uno should at least be looked at when judging
| which framework to use. They are both quite mature and have many
| great controls and features built in.
|
| [1] https://avaloniaui.net/ [2] https://platform.uno/ [3]
| https://platform.uno/docs/articles/external/uno.extensions/d...
| [4] https://github.com/AyanamiKaine/Ayanami-
| sTower/blob/main/Ava... [5]
| https://github.com/AyanamiKaine/Ayanami-sTower/blob/main/App...
| chiengineer wrote:
| I built multiple Avalonia apps with zero previous experience
|
| - Windows 11 Hardening utility - made it because all existing
| ones are not updated to handle all the new AI telemetry + new
| updates + I made it differently and more powerful than anything
| that exists currently
|
| - Windows Admin/ Security / Networking Utility built for my
| needs
|
| - Windows 11 Anti Virus Nuker - Completely shuts off windows
| defender without disrupting system performance or zombie files
|
| - and more
| domenicd wrote:
| They are both mentioned in the article. But I appreciate the
| extra experience and details, beyond what I got from browsing
| their landing pages and GitHub repos.
| jbm wrote:
| > 9 MiB
|
| I'm glad people still care about stuff like this. It drives me
| insane that the simplest form-based software that I build and
| compile ends up being 50-100 MiB; several times video games from
| the 80s that I grew up with that did much more complex work,
| graphically and computationally, on a tenth of the space.
| drnick1 wrote:
| > But, in 2026, writing a greenfield application in a memory-
| unsafe language like C++ is a crime.
|
| I disagree, the GUI layer is far from behind a safety critical
| component, and C++ is a battle-tested choice for everything from
| GUI, videos games, to industrial applications. If C++ is safe
| enough to control airplanes and nuclear reactors when used well,
| it is certainly safe enough for something as trivial a GUI.
|
| The article also fails to mention frameworks like Qt, arguably
| the best way to write GUI apps in 2026. Qt is native (C++), has
| built-in memory safety features (but no GC), and is cross-
| platform.
| KellyCriterion wrote:
| ...but it is comfortable and actually a PITA compared to any
| managed execution environment :-)
|
| Sure, embedded systems are a different anmial...
| glitchc wrote:
| Yet we cannot consider Qt to be native app development since
| every app requires the Qt runtime. Native means system
| libraries only.
| 201984 wrote:
| >Native means system libraries only.
|
| Since when? To me, anything not webview-based is native,
| though you have varying degrees of integration into the
| platform.
| Rohansi wrote:
| Why single out WebViews? Would you consider Flutter native?
| It renders widgets on its own just like a WebView does.
| 201984 wrote:
| Most toolkits, including WebUI 3.0, render widgets on
| their own, so you can't distinguish just on that. I'd say
| anything written in an interpreted language is not
| native, and Javascript falls into that category. Dart at
| least is possible to compile ahead of time, and so is C#.
| debazel wrote:
| WebViews aren't written or rendered with interpreted
| languages either. It is also usually not Javascript that
| makes browser based apps so heavy. It is almost always
| the whole browser stack that is making them large and
| memory hungry, which is mostly written in C++.
|
| You can also hook a WebView up directly to a low-level
| language and skip Javascript entirely, so does that mean
| Rust + WebView = Native?
| jcelerier wrote:
| For me, native means "I can integrate a platform widget
| in the middle of it". For instance, with Qt, GTK or
| wxwidgets it's entirely possible to integrate a Win32 /
| Cocoa / X11 component right in the middle of your app
| (and it's super important for instance for things such as
| integrating audio plugins, where the plugin only gives
| you a HWND or NSView and you have to draw your
| application Chrome around it, have it follow resizes,
| etc.)
| mycall wrote:
| So then flutter will let you do that, with a little elbow
| grease.
| drnick1 wrote:
| I have always considered Qt apps (even for Windows) to be
| native. Think of VLC, VirtualBox, etc.
| userbinator wrote:
| I'd consider them "naturalized"; close enough to native
| that you wouldn't notice any big differences, but there are
| still minor ones if you know what to look for.
| spacechild1 wrote:
| There is no Qt "runtime". Qt is just a library.
|
| > Native means system libraries only.
|
| Every non-trivial application will eventually use third-party
| non-system libraries.
|
| I think "Native app development" has at least two meanings:
|
| 1. narrow meaning: the program uses a native UI toolkit
| (Win32, Cocoa)
|
| 2. broad meaning: the program targets one or more specific
| platforms and the UI is not not just a webview
|
| Even with the narrow meaning, WxWidgets would qualify as
| "native development" (because it uses native UI toolkits
| under the hood), yet it is still a third-party library.
| vovavili wrote:
| Why would the article mention Qt? Qt is native for a subset of
| Linux distributions, not Windows.
| jcelerier wrote:
| Even Microsoft shipped Qt apps as part of Windows though, for
| instance onedrive
| hermitcrab wrote:
| Qt for Windows compiles to a win32 or win64 .exe. That is
| native in my book.
| hxorr wrote:
| Qt is arguably the best cross platform toolkit to target when
| writing big/complex apps
| kantselovich wrote:
| Thank you for the detailed write up.
|
| I'm was thinking about building native windows UI, wrapping
| around cross platform library written in swift. I did not know it
| was that messy and complicated.
| fermentation wrote:
| The Windows code signing experience has prevented me from
| shipping apps that otherwise run perfectly fine on the platform.
| It is a nightmare and I cannot believe it wasn't called out in
| the "We want to fix Windows" blog post.
|
| Just do exactly what Apple does. Charge me $100 directly from you
| and let me build an .exe that I can distribute on my website.
| vegasje wrote:
| This isn't well-known, so I figured I'd mention it.
|
| Microsoft offers a service called Azure Artifact Signing (used
| to be called Trusted Signing) that manages code signing for
| you:
|
| https://azure.microsoft.com/en-us/pricing/details/artifact-s...
|
| It's $9.99/mo, and you don't need to worry about procuring or
| renewing code signing certs.
| fermentation wrote:
| Except this requires you to own a business for 3+ years,
| which makes it a non-starter for indie apps.
| domenicd wrote:
| US and Canada residents only, sadly.
| pjmlp wrote:
| Again, unless you have existing Windows 8/10 applications that
| were written against WinRT, UAP or UWP[0], that make use of WinUI
| 2.0, forget about touching anything related to WinUI 3.0 or
| WinAppSDK, stay away from the marketing.
|
| Exception being the few APIs that have been introduced in Win32
| that instead of COM, actually depend on WinRT like the new MIDI
| 2.0 or Windows ML.
|
| Keep using Win32, MFC (yes it is in a better state than WinUI 3.0
| with C++), WinForms, WPF, if using Microsoft only tooling.
|
| Otherwise, Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI,....
|
| They were even forced to revamp WPF status at BUILD 2024, given
| how bad WinUI 3.0 was back then, and it isn't if it got any
| better, apparently it is in the process of being open sourced, to
| see if the community can take over the mess a $4 trillion valued
| company cannot fix.
|
| Really, stay away from WinUI, unless you're a Microsoft employee
| on the Windows team without any other option.
|
| [0] - Can explain by the nth time the differences, if one feels
| like it.
| nozzlegear wrote:
| Just wanted to add a shoutout to WinJS for posterity, with
| which I built a Windows 8 app that I had published to the
| Windows Store for a brief period of time. Then they open-
| sourced the UI part of WinJS and decided it was just a web
| framework instead of an officially supported method for
| building Windows apps iirc, which was the end of my foray into
| the Windows store.
|
| https://github.com/winjs/winjs
| Klonoar wrote:
| If you want JS, isn't react-native-windows an option?
| nozzlegear wrote:
| It probably is now, but I don't think it was at the time.
| This was back in the early Windows 8 era, when apps were
| called "Metro" - 2012 to 2015 I think? I'm primarily a .NET
| dev by trade, but I wanted to try something different with
| WinJS so invested time in learning that.
| pjmlp wrote:
| I have a WinJS book somewhere, from Microsoft Press.
|
| When it was announced at PDC, they only talked about WinJS
| and nothing else, the folks of .NET Rocks have a few shows
| where they mention they thought .NET was done, and they
| needed to refocus into something else.
|
| The show where they interview Miguel de Icaza they go into
| this.
| jerhewet wrote:
| > for posterity
|
| Anyone remember this one?
|
| Microsoft Press: Learn Java Now (complete with J++
| installation CD). https://www.amazon.com/dp/1572314281
| jeremycarter wrote:
| The CD is available on Archive.org
| domenicd wrote:
| I was actually part of a team at Barnes & Noble.com which
| tried to use WinJS for a serious application. (We were
| previously using Chromium Embedded Framework, or our own
| hand-rolled WebKit integration, for the desktop e-reader.)
|
| It didn't go great. I gave a talk about it.
| https://youtu.be/HySQR0t_7CI?si=5sfKbb-7u-qqD65R . (Be gentle
| to my 2012 self's speaking skills.)
| layer8 wrote:
| In that light, it is troubling that Friday's blog post [0]
| announced "moving core Windows experiences to the WinUI3
| framework" as a measure to improve the quality of said
| experiences.
|
| [0] https://blogs.windows.com/windows-insider/2026/03/20/our-
| com...
| pjmlp wrote:
| As long as it only applies to Microsoft employees, maybe the
| pain using C++/WinRT will finally improve the Visual Studio
| tooling for the rest of us, but I doubt it.
|
| Thus better leave WinUI to the Windows team.
| NetMageSCW wrote:
| The only good thing to say about that is it removes the
| stupidity of using Electron (or the Microsoft Edge
| equivalent) for built-in Windows apps and the Start Menu.
| SMH.
| bigfatkitten wrote:
| Whoever was responsible for that should be fired.
| dminik wrote:
| The start menu never was electron. It's react native
| desktop. So, nodejs creating and updating native (well,
| winui 3) controls.
| fodkodrasz wrote:
| These steps are necessary stepping stones in getting the
| thing good, the question is, given Microsoft's tendency to
| abandon UI frameworks halfway, apart from the classical ones
| listed above, is if they will keep it focused until its gets
| as mature as those.
| TheJoeMan wrote:
| I'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 sure what they are each "built-with".
| domenicd wrote:
| 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 safety angle.) I might do a follow-
| up asking Claude to reproduce my UI in the various frameworks
| to test. But my strong guess is that we just have a bunch of
| HackerNews curmudgeons who are happy to foist pixelated Vista-
| era light-mode-only UIs on their users.
|
| [1]:
| https://github.com/dotnet/winforms/issues?q=is%3Aissue%20sta...
| xg15 wrote:
| > _One might think that an advantage of controlling C# would be
| that Microsoft has carefully shaped and coevolved it to be the
| perfect programming language for Windows APIs. This does not
| appear to be the case._
|
| I think they spent all their mana for that on pre-.NET Visual
| Basic and then had nothing left.
| Kwpolska wrote:
| > 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 as a runtime like Java or Python.
|
| ---
|
| Regarding tray icons, 1Password, Signal, and Discord are all
| Electron apps, so they are using Chrome's UI toolkit, and its
| menu component.
|
| Myself, I'm happy with WPF. Starting with .NET 9, it comes with a
| really good WinUI-style theme.
| NetMageSCW wrote:
| .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.
| Kwpolska wrote:
| Microsoft promises things included with Windows will be
| supported ~forever. Adding modern .NET into the mix would
| break this promise and add more churn.
|
| Automatically uninstalling .NET runtimes would break apps,
| and Microsoft will be to blame, not app vendors who failed to
| upgrade to the latest .NET. An app built for .NET 8 can run
| on .NET 10, assuming no backwards-incompatible changes in the
| runtime and system libraries, but this behavior is opt-in.
| piskov wrote:
| Last time I heard WPF was basically abandoned (open-sourced)
| and handed over to die to some Indian folks.
|
| Something akin to WCF
| hestela wrote:
| When I tried to release a flutter app via exe installer, google
| drive said it was a virus but it otherwise installed just fine in
| windows 10/11. I'm doing the same thing for msix for now. But
| when I searched for certificates I could only find closer to
| $200/yr and you need to load it in the latest $100 yubikey due to
| the fips requirement. I didn't realize that CAs dont let you just
| get the private/public key files any more. Only distribution
| method is hardware based fips key. I've given up entirely on code
| signing since I only made a single open source project for
| amateur radio.
| NetMageSCW wrote:
| Excellent summary of the stupid state of Windows native GUI app
| development after the complete lack of direction or coherence
| Microsoft has shown. Not to mention the irony of Visual Studio
| not having a GUI designer for anything except Windows Forms.
| domenicd wrote:
| A lot of people complain about this, but there seemed to be a
| reasonable XAML designer when I was making my WinUI 3 app. I
| didn't really use it (my app was simple enough that hand-
| crafting the XAML felt worthwhile to ensure everything was
| nicely aligned and not full of any unnecessary designer gunk).
| So I suspect it does suck, since otherwise people would not
| complain as much. But one does exist.
| cosmotic wrote:
| This all seems like a direct result of measuring employee
| performance using "impact".
| Andrex wrote:
| *has been for 20+ years
|
| Meanwhile editions of Gnome come with Gnome Builder and Flatpak
| has solved the distribution problem. Things are so much better
| today on Linux than most people who have used Windows will even
| remember.
| Dig1t wrote:
| >Displaying a tray icon with a few menu items: not available. Not
| only does the tray icon itself need P/Invoke, the concept of
| menus for tray icons is not standardized
|
| Having never written Windows apps, I am surprised to learn how
| disorganized and chaotic this all is.
| FpUser wrote:
| You missed something.
|
| With Delphi creating of Native Windows Desktop Applications is a
| piece of cake (also does MacOS, iOS, Android and partially
| Linux). Yes it is by now obscure and expensive tool but I still
| use it to maintain my existing native GUI desktop applications.
| It is incredibly easy to use / develop with and single exe no
| dependencies deployment mode is superior. Compatibility between
| Windows versions is stellar as well.
|
| There is also an opensource version of Delphi called Lazarus
| which is way less polished.
| Pesthuf wrote:
| Thanfully, you don't need to write p/invoke stuff yourself
| anymore. https://github.com/microsoft/cswin32 creates methods and
| all related structs for you. It's also AOT compatible (if you
| specify it). It works for calling C and COM functions.
|
| I mean, not like this brings Windows development anywhere close
| to "modern", if anything, it feels like you're moving into the
| opposite direction, but at least this solves the "The modern APIs
| don't provide the specific functionality I need" problem that
| plagues all of Microsoft's "nice", "modern" abstractions...
| domenicd wrote:
| This is discussed in the article, including why I tried it and
| ended up reverting to normal P/Invoke.
| userbinator wrote:
| 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 wrote:
| How do you make your win32 app look good to the average person?
| themafia wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Programmers and designers thinking the average person is
| a moron is one of the two reasons almost no good software
| is writren today.
| userbinator wrote:
| 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.
| lelandfe wrote:
| There's a pretty simple settings window:
| https://github.com/domenic/display-blackout?tab=readme-ov-
| fi...
|
| Would that UI be hard to accomplish?
| alt227 wrote:
| Disable borders and design your app nicely with images to
| replace standard user input elements.
| VerifiedReports wrote:
| 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.
| pjc50 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| _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 wrote:
| Yes, of course they were smarter.
| kulahan wrote:
| Software seems to have quality and capability as
| diametrically opposed attributes.
| ojeda wrote:
| 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
| bigstrat2003 wrote:
| The answer to your question of "why not Electron" at the end is:
| because then your app will suck. You've laid out the reasons why
| native apps are harder to make, but the reality is that Electron
| trades your ease of development for the user having a crappy
| experience. If you care about producing a good product, then you
| have to suck it up and make the native app even if it is harder.
|
| Also, I think C# is miles better than TypeScript, but that's just
| my preference.
| hyperpl wrote:
| I used to code Win32 around the Win 95/98/2000 era (my first VC++
| was 1.0 for 16bit) but switched to BSD and Linux around 2000 and
| haven't looked back. I avoid Windows as much as possible and did
| learn about .NET and how slow it was but I'm a bit shocked that
| Win32 is still a thing and still being recommended. Sort of makes
| me happy and sad at the same time...
| int_19h wrote:
| .NET is blazing fast by modern standards (given that the
| typical app experience these days is Electron, meaning
| Node.js).
| rahimnathwani wrote:
| It had been many years since I last developed a desktop app. A
| couple of weeks ago I used Tauri to create a simple app for
| Windows and Mac. Developing the app was easy with Claude.
| Building the app for different platforms and architectures was
| easy with GitHub Actions.
|
| But after I had the msi and dmg files, my non-techy colleagues
| couldn't install the apps because they weren't signed. The
| workaround for Mac was fine (remove the quarantine attribute on
| the installer) but for Windows my colleague had to disable Smart
| App Control (SAC), which cannot be re-enabled without re-
| installing Windows.
|
| I get the point of these protections, but the difficulty of
| getting past them surprised me. I thought that on Mac you should
| just go to settings -> security and click 'Allow Anyway'. And
| that on Windows you'd get a GUI warning that would need admin
| privileges to get past. But MacOS needed a terminal command, and
| Windows needed a control panel setting change.
| tehologist wrote:
| TCC supports win32 and is less than a meg download and as an
| added bonus supports linux very well thanks to wine.
| tehologist wrote:
| TCC is less than a meg to download supports win32 very well and
| as an added bonus created executables run fine under linux wine.
| jerhewet wrote:
| Steve Gibson, Gibson Research.
|
| https://www.grc.com/freepopular.htm
|
| Just scroll down the page and look at the size of the _completely
| self-contained_ executable programs. THIS is what Win32 is
| capable of. Something we _always_ had with Win32 that was thrown
| away with .Net and C#.
|
| And _please_ just spare me your opinions of how Steve Gibson
| "doesn't know anything about security". That's not what's
| important here. What's important is _how freakin ' small his
| full-on GUI stand-alone executables are_.
|
| EDIT: Just noticed this on his page.
|
| Total Historical Count of files downloaded from this page:
| 52,292,601
| int_19h wrote:
| .NET runtime has been bundled with Windows since Win2003.
|
| And if you don't have to drag the runtime around, .NET binaries
| are even smaller than that, since the bytecode is more compact.
| kelvinjps10 wrote:
| I got burned out of windows development. I was building a desktop
| app and switched from WPF to UWP because I wanted the new fluent
| design widgets, but then Microsoft deprecated it towards WINDOWS
| UI but it didn't have the same features than wpf.
| abcde666777 wrote:
| 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.
| c-smile wrote:
| It is not. Not to that extent at least.
|
| I am developing Sciter[1] engine that works on all desktops:
| Windows, MacOS, Linux (3 distinct backends: pure X11, pure
| Wayland and GTK4).
|
| Among all those, Windows API is still the most consistent and
| stable.
|
| Whole of Windows functionality can still be accessed by plain C.
| For some things (COM) is better to use C++ but C works too.
|
| Just in case: I am in this business for 20+ years.
|
| [1] sciter.com
| bullen wrote:
| I wrote a Win32 app 20 year ago, but the limits to how it handles
| memory made things confusing when you loaded large amounts of
| data into the GUI.
|
| I would say Java Swing is still the peak of GUI development.
| Works flawlessly at close to native speeds (GPU acceleration and
| all) on all platforms including Risc-V that did not exist when it
| was developed!
|
| The JVM is the emulator!
| jongjong wrote:
| Microsoft has been butchering software development for decades
| and maintaining dominance through pure business, legal and
| government connections. It's become like Oracle.
|
| Developers being forced to use horrible Microsoft products is the
| logical consequence of that.
|
| As a software engineer, most of my job exists to give credibility
| to the narrative that Microsoft is useful... And I don't even
| work for Microsoft. It's clear that there are deals behind the
| scenes which force many large companies into Microsoft contracts.
| The engineers have to work with what they get and pretend the
| tech is OK but behind the facade, it's clear from the jokes on
| the Microsoft Teams chats that they think differently!
___________________________________________________________________
(page generated 2026-03-22 23:00 UTC)