11 ms·

Windows native app development is a mess

• ashwinnair99 7mo ago
  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 7mo ago
    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 7mo ago
      > (Win11 reverts). I must've missed that one. What did they revert?
      • lpcvoid 7mo ago
        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-commitment-to-windows-quality/ https://blogs.windows.com/windows-insider/2026/03/20/our-com...
        • Traubenfuchs 7mo ago
          "File explorer launch experience" -hard to tell if this is satire…
          • Smalltalker-80 7mo ago
            I did mean these, very recent promises (vaporware at this moment), without satire. https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/ https://blogs.windows.com/windows-insider/2026/03/20/our-com...
    • anonymars 7mo ago
      > 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 7mo ago
      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/windows-10-build-15063-api-diff 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 7mo ago
    > 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 7mo ago
    [flagged]
    • int_19h 7mo ago
      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 7mo ago
  > 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 7mo ago
    When Microsoft themselves use electron to develop apps what expectations can we have on other devs?
    • Sindisil 7mo ago
      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 7mo ago
        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 7mo ago
        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 7mo ago
        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.
• intrasight 7mo ago
  "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 7mo ago
    "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 7mo ago
      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 7mo ago
    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.
• mococa 7mo ago
  Best framework for this is Qt.
  • madduci 7mo ago
    MFC is rock solid too
    • adzm 7mo ago
      WTL and ATL also, especially if you need to do com stuff
      • pjmlp 7mo ago
        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 7mo ago
    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 7mo ago
    And Lazarus/FPC.
  • hliyan 7mo ago
    I've recently discovered FLTK: https://www.fltk.org/doc-1.4/intro.html 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-add.cxx https://github.com/fltk/fltk/blob/master/examples/menubar-ad...
    • deleted 7mo ago
      [deleted]
• ozim 7mo ago
  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 7mo ago
    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 7mo ago
    Isn’t Microsoft also using React native for desktop stuff?
  • Boxxed 7mo ago
    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 7mo ago
    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 7mo ago
    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 7mo ago
      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.
• cv5005 7mo ago
  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 7mo ago
    Winforms? lol at them still bekng the best option. so much wasted effort trying to replace them
    • pjc50 7mo ago
      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 7mo ago
        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.
        • deleted 7mo ago
          [deleted]
        • bob1029 7mo ago
          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%20state%3Aopen%20label%3Aarea-HDPI-SA https://github.com/dotnet/winforms/issues?q=is%3Aissue%20sta...
• bentt 7mo ago
  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?
  • fsloth 7mo ago
    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 7mo ago
      > 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.
      • fsloth 6mo ago
        A professional GUI requires quite a lot. A Unity expert can correct me, but IIRC (possibly wrongly) at least the following limitations apply: For example Unity does not have accessibility features (screen readers etc) nor I don’t think it’s DPI aware. I would _guess_ it does not support platform fonts. Not sure if it supports non-latin font layouts like arabic. Etc etc.
  • v9v 7mo ago
    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_applications.html https://docs.godotengine.org/en/stable/tutorials/ui/creating...
  • pier25 7mo ago
• lpcvoid 7mo ago
  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 7mo ago
    Lazarus is probably the easiest way to make a lean and fast native Windows app without paying for tooling.
  • throwaway2046 7mo ago
    wxWidgets is just a wrapper around existing UI libraries; win32 on Windows, and Gtk/Qt on *nix.
    • lpcvoid 7mo ago
      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 7mo ago
  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.
  • kristianp 7mo ago
    Looks like Tcl is still being developed, with 64 bit version released in 2024 [1]. How big is your software, is it mainly C code wrapped in Tcl for the GUI? [1] https://en.wikipedia.org/wiki/Tcl_(programming_language) https://en.wikipedia.org/wiki/Tcl_(programming_language)
• whobre 7mo ago
  Interestingly, no mention of WTL
  • domenicd 7mo ago
    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 7mo ago
      > 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
      • badsectoracula 7mo ago
        > This is why... ...but they were correct. The GP just didn't remember the proper name and asked about a different thing.
    • int_19h 7mo ago
      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 7mo ago
  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 7mo ago
    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 7mo ago
      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 7mo ago
    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 7mo ago
• samiv 7mo ago
  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 7mo ago
    Just write C++ safely! Why didn't we think of that?
    • array_key_first 7mo ago
      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 7mo ago
    Yeah he literally answered his own question and then used a random excuse for not going with the option.
• livinglist 7mo ago
  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 7mo ago
  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 7mo ago
    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 7mo ago
  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 7mo ago
    Delphi or Lazarus (https://www.lazarus-ide.org https://www.lazarus-ide.org) should solve it.
    • rwmj 7mo ago
      Nice, I didn't know there was a free software version of Delphi nowadays.
      • dardeaup 7mo ago
        With restrictions of course.
        • deleted 7mo ago
          [deleted]
      • kwanbix 7mo ago
        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 7mo ago
    > 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.
• LocalH 7mo ago
  WinForms forever :evil:
• GeoAtreides 7mo ago
  come back home Delphi 7, all is forgiven
  • dardeaup 7mo ago
    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 7mo ago
      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 7mo ago
      I think WinForms with C# or VB is as good, if perhaps not as fun or approachable.
    • int_19h 7mo ago
      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 7mo ago
  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 7mo ago
    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 7mo ago
      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 7mo ago
      If .NET had a desktop UI for Linux it might be worth it for me, but we haven't gotten there yet somehow.
      • Marsymars 7mo ago
        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.
• mellosouls 7mo ago
  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 7mo ago
  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 7mo ago
  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 7mo ago
  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…
  • 6yyyyyy 7mo ago
    You should run away from React Native Desktop screaming. It's built on top of WinUI 3, and inherits all it's problems, while also being dramatically slower. Almost all functionality requires writing C++ code, and communicating between C++ and JS is a huge pain in the ass. Use QT instead. And if you think using it will let you port your app to other platforms, think again. There's no drop-in compatible equivalent of RNW for Linux, and the version for Mac is even worse than the Windows version. t. works on a huge app written with React Native Desktop
    • jasonjei 6mo ago
      Thanks for the heads up! In all fairness, I'd probably run away from writing any more desktop apps!
• stefantalpalaru 7mo ago
  [dead]
• apankrat 7mo ago
  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 https://bvckup2.com/wip
  • domenicd 7mo ago
    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-windows-how-many-layers-of-ui-inconsistencies-are-in-windows-11/ https://ntdotdev.wordpress.com/2023/01/01/state-of-the-windo...
    • apankrat 7mo ago
      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 7mo ago
      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.
      • dspillett 7mo ago
        > but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland I've been around long enough to remember MS and their fans banging on about how bad other OSs were for their inconsistent interfaces, so I feel justified in getting a little riled at the hypocrisy of how much of a mess UIs are in Windows these days. And I don't see it getting any better - they'd rather spend the time finding new places to slip in adverts. And this is far from the fault of app developers, while they often do have something to answer for wrt consistency, because the worst culprit is MS themselves both in their apps and the OS. I shouldn't have to click to make sure the right thing has focus for instance, particularly after switching from another virtual desktop, I should be able to see this information easily but there is no consistency in titlebars and other window chrome any more.
• MomsAVoxell 7mo ago
  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 7mo ago
    Given OS windows shares, if you are writing desktop, cross platform makes no sense for most apps.
    • aa-jv 7mo ago
      .. except for where it does make sense, for example, you have applications that you want to deliver to MacOS, Linux and Windows users. Windows is less and less relevant these days - especially when one takes the bull by the horns and deliver cross-platform apps on purpose.
• iamcalledrob 7mo ago
  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 7mo ago
    > "(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 7mo ago
      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 7mo ago
      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.
• ilovecake1984 7mo ago
  There seems a lot of conflation between GUI frameworks and interacting with the OS in this article.
• AyanamiKaine 7mo ago
  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/ https://avaloniaui.net/ [2] https://platform.uno/ https://platform.uno/ [3] https://platform.uno/docs/articles/external/uno.extensions/doc/Learn/Markup/Overview.html https://platform.uno/docs/articles/external/uno.extensions/d... [4] https://github.com/AyanamiKaine/Ayanami-sTower/blob/main/Avalonia/Avalonia.Flecs/Avalonia.Flecs.ToDoApp/App.axaml.cs https://github.com/AyanamiKaine/Ayanami-sTower/blob/main/Ava... [5] https://github.com/AyanamiKaine/Ayanami-sTower/blob/main/Applications/SmartTrashTrayIcon/App.axaml.cs https://github.com/AyanamiKaine/Ayanami-sTower/blob/main/App...
  • chiengineer 7mo ago
    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 7mo ago
    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 7mo ago
  > 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 7mo ago
  > 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 7mo ago
    ...but it is comfortable and actually a PITA compared to any managed execution environment :-) Sure, embedded systems are a different anmial...
  • glitchc 7mo ago
    Yet we cannot consider Qt to be native app development since every app requires the Qt runtime. Native means system libraries only.
    • 201984 7mo ago
      >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 7mo ago
        Why single out WebViews? Would you consider Flutter native? It renders widgets on its own just like a WebView does.
        • 201984 7mo ago
          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#.
• kantselovich 7mo ago
  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 7mo ago
  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 7mo ago
    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-signing/ 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 7mo ago
      Except this requires you to own a business for 3+ years, which makes it a non-starter for indie apps.
      • delta_p_delta_x 6mo ago
        Not anymore: Artifact Signing is now generally available (GA), to anyone with an Azure account in the US, Europe, or the UK[1]. [1]: https://techcommunity.microsoft.com/blog/microsoft-security-blog/simplifying-code-signing-for-windows-apps-artifact-signing-ga/4482789 https://techcommunity.microsoft.com/blog/microsoft-security-...
    • domenicd 7mo ago
      US and Canada residents only, sadly.
      • delta_p_delta_x 6mo ago
        See my sibling reply[1]. [1]: https://news.ycombinator.com/item?id=47507201 https://news.ycombinator.com/item?id=47507201
• pjmlp 7mo ago
  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 7mo ago
    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 https://github.com/winjs/winjs
    • Klonoar 7mo ago
      If you want JS, isn’t react-native-windows an option?
      • nozzlegear 7mo ago
        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.
      • smileybarry 7mo ago
• TheJoeMan 7mo ago
  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 7mo ago
    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%20state%3Aopen%20label%3Aarea-HDPI-SA https://github.com/dotnet/winforms/issues?q=is%3Aissue%20sta...
    • Joker_vD 7mo ago
      I have 15 year old binaries made with WinForms that look just fine on Windows 10, and use native Windows 10-styled controls.
    • SirMaster 7mo ago
      >with no dark mode support. https://learn.microsoft.com/en-us/dotnet/desktop/winforms/whats-new/net100 https://learn.microsoft.com/en-us/dotnet/desktop/winforms/wh... "Dark mode Windows Forms has fully integrated dark mode support. Windows Forms for .NET 9 introduced preliminary dark mode visual styling, but in an opt-in preview mode where you had to suppress Compiler Error WFO5001 to use the feature. This feature is no longer guarded behind this compiler error starting with .NET 10. The Application.SetColorMode(SystemColorMode) API is no longer considered experimental."
• xg15 7mo ago
  > 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 7mo ago
  > 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 7mo ago
    .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 7mo ago
      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.
    • kristianp 7mo ago
      .Net releases are installed side-by-side. I agree with the Author that a more recent minimum install of the framework would make sense, especially with the existence of LTS releases of .net [1], seems to be every 2nd major version. I don't agree with the argument that Windows would have to guarantee a particular version is installed. If an app requires .net 8 and .net 10 is installed, the app can install .net 8 next to version 10. It would however require different silos within Microsoft to communicate and plan together. .Net 4.81 is the last one before .Net Framework was unified with .Net Core. It's very legacy by now, but there would be many enterprise/business apps that still require it. [1] https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core https://dotnet.microsoft.com/en-us/platform/support/policy/d...
• hestela 7mo ago
  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 7mo ago
  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 7mo ago
    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 7mo ago
  This all seems like a direct result of measuring employee performance using "impact".
• Andrex 7mo ago
  *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 7mo ago
  >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 7mo ago
  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 7mo ago
  Thanfully, you don't need to write p/invoke stuff yourself anymore. https://github.com/microsoft/cswin32 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 7mo ago
    This is discussed in the article, including why I tried it and ended up reverting to normal P/Invoke.
• userbinator 7mo ago
  I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid. Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that: Enumerating the machine’s displays and their bounds A few API calls. Probably a few hundred bytes. Placing borderless, titlebar-less, non-activating black windows Creating non-functional windows is trivial. Another few hundred bytes at most. Intercepting a global keyboard shortcut A few dozen bytes to call SetWindowsHookEx. Optionally running at startup Write to the appropriate registry key. A few hundred bytes. Storing some persistent settings Ditto. Another few hundred bytes. You can use a .ini file too, for around the same size. Displaying a tray icon with a few menu items Most of this size of this will be the icon itself - a few kilobytes; the next biggest contributor will be text strings; and the rest is accomplished with a few hundred bytes of API calls. Add another few hundred bytes of (not much) logic, round up to a kilobyte and add maybe another for general overhead. But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime. Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
  • feznyng 7mo ago
    How do you make your win32 app look good to the average person?
    • themafia 7mo ago
      If your application saves me time (is intuitive) or enables me to do tasks that I couldn't do before (is powerful) then I don't care one whit what it looks like. As long as it doesn't actively hurt my eyes to stare at you can do whatever you want.
      • feznyng 7mo ago
        Sure, if I'm building something for myself or fellow hobbyists this approach works (though in that case I'd prefer a good TUI/CLI). But if you're building an app for the average person, how it looks has a big effect on whether they choose it over an alternative.
• bigstrat2003 7mo ago
  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 7mo ago
  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 7mo ago
    .NET is blazing fast by modern standards (given that the typical app experience these days is Electron, meaning Node.js).
• rahimnathwani 7mo ago
  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 7mo ago
  TCC supports win32 and is less than a meg download and as an added bonus supports linux very well thanks to wine.
• tehologist 7mo ago
  TCC is less than a meg to download supports win32 very well and as an added bonus created executables run fine under linux wine.
  • leecommamichael 6mo ago
    Why wouldn't it?
• jerhewet 7mo ago
  Steve Gibson, Gibson Research. https://www.grc.com/freepopular.htm 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 7mo ago
    .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 7mo ago
  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 7mo ago
  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.
  • scotty79 7mo ago
    I feel like WinForms was peak (because it was close to Delphi) and it went downhill from there.
    • badsectoracula 7mo ago
      IMO WinForms didn't manage to reach even Delphi 2's state, so i'd say it is far from peak considering the improvements later Delphis (and now Lazarus) added. It was abandoned too soon.
      • scotty79 7mo ago
        I meant peak for MS. > It was abandoned too soon. This is probably a recurring theme for MS UI frameworks.
• c-smile 7mo ago
  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 7mo ago
  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 7mo ago
  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!
• 9cb14c1ec0 7mo ago
  Small nitpick. 4.8.1 was .NET Framework, which is a totally different beast that .NET (1 through 10). .NET Framework was heavily dependent on Windows, while .NET (1 through 10) are the newer OS independent system. It's not that they've forgotten to update the system .NET, its that that product is in long term maintenance only mode and modern .NET is a totally different software.
• hernandipietro 7mo ago
  I use WTL with modern C++ (smart pointers, Microsoft WIL for scoped handles is a good point) for suitable Windows native apps. Yes, this seems to be old but it’s the only thing that fits my mental model as a 30 year old Windows programmer as you.
• naizarak 7mo ago
  For anybody interested in the use-case underlying this article, mainly disabling peripheral displays in a multi-monitor setup, this is already built into Windows via the Win+P hotkey. It's also possible to turn off all displays by reassigning the functions of the computer's physical power/sleep buttons in Control Panel -> Power Options.
  • dlopes7 7mo ago
    This is not the same at all, you are pretty much turning the screen off with that
    • naizarak 7mo ago
      Isn't that the point? What's the benefit of blacking-out a display instead of putting it in no-signal standby?
      • domenicd 6mo ago
        This is covered in the article: > Turning them off will cause Windows to spasm for several seconds and throw all your current window positioning out of whack.
• MintPaw 7mo ago
  What kind of experience you have is about what kinda of developer you are. If you're the kinda programmer who wants to use all the newest versions of stuff because you think it'll be better, then you'll be in an endless quagmire of hitting limitations. Most web programmers fall into that bucket for example. If you're the type to recoil at XMLHttpRequest, reaching to fetch or other even newer stuff. Then you'll balk at Win32 and be in a never ending pit of new Windows technology. I'd argue this is true of basically all new software. It's worth starting with whatever the oldest most compatible version of your target and ignoring the advertising and hype.
• sitzkrieg 7mo ago
  2026 and people are complaining about the oldest, most stable gui api available, seems right on target
• rock_artist 7mo ago
  Microsoft approach is similar to the C++ approach where new way or feature won’t cut the older feature/way of doing things. I’ve heard Bjarne Stroustrup once in a lecture explaining the value of this approach as the language is used in so many fields and that it’s important for all code to compile allowing gradual migration. In some ways, Microsoft is similar to that. Apple on the other hand is fast paced so API can suddenly be deprecated and slashed and with Swift they’ve also made a language that is being changed from time to time in a breaking way. While Microsoft’s approach similar to C++ it is a private company with no committee. This allows fast pace for ideas needed by a company in a competitive market. But, with ensuring backward compatibility, it makes each not throughly thought design -stick. I guess Win32 is an exception since the first GUI concepts, our desktop designs hasn't changed that much. Window, Menu, Toolbar. Back then, The competition and pace was less intense allowing more time to think. There were other constraints of course being applied by the hardware and stack available back then requiring more abstract designs. In that sense, it’s quite interesting to see Win32 is kept while Apple’s switch to NS/OSX made everyone eventually transition into Cocoa.
• yalvhe2009 7mo ago
  [flagged]
• wolvesechoes 7mo ago
  Honestly, if app complexity and size justifies few more MBs of bloat, Python + Pyside is the best option to make UIs, be it Win-only or cross-platform. You get the power of Qt with stuff like hardware-accelerated QGraphicScene exposed via nice, concise, high-level language that also gives you access to some best-in-class libraries. Performance hit is negligible if you know what you are doing (what may not be the case in 2026 and age of vibe-coding). Unless, of course, you tend to whine about "complex licensing", i.e. people wanting to make money as you do.
• DeathArrow 7mo ago
  Why do people conflate "writing GUI apps" with "native app development" and "low level access"? If you need low level access to the operating system and the hardware, you need Win32, so you need C/C++. And there's no way around it. Expecting .NET apis to give you low level access in Windows is akin to expecting Go apis to give you low level access in macOS or using Haskell to interact with hardware on Linux.
• teki_one 7mo ago
  The problem is not new: https://devblogs.microsoft.com/cppblog/mfc-update-powered-by-bcgsoft/ https://devblogs.microsoft.com/cppblog/mfc-update-powered-by...
• ymolodtsov 7mo ago
  The more I learn about all the frameworks for Windows, the more I believe they should have just switched to web development. Make it native to the platform, fork Electron to enable Edge runtme with some shared resources, and then they'd have a more thriving app ecosystem at least.
• d3vguy 7mo ago
  The only modern and battle-tested UI framework on Windows is WPF. Going for .NET Fremework 4.8 in the back is smoothest to avoid users needing to install runtime (comes with Windows), but if Microsoft ever decides to include one of LTS versions (NET8 or NET10) this recommendation would change. Nobody likes web technologies for desktop except lazy developers who know only that and try to make everything fit their world. WinUI3 is so buggy that not even their UI controls samples app can run for more than 5 minutes without crashing. Pinvoke is reality on Windows and it is fine. COM is garbage but that's what we've got to maintain compatibility across 30 years. Windows is held by duct-tape and chewing gum and that is just reality
• HackerThemAll 7mo ago
  Unpopular opinion: FreePascal is perfectly capable of all that and produces tiny native executables. Their clone of Delphi's Visual Component Library - Free Component Library - is rich in features and don't change every year like those Microsoft toolkits. I needed recently to make an exe that would work on anything from 32-bit Windows 95 up to and including Windows 11 (to accommodate some old machines on production lines), and the only language that made that easily achievable was FreePascal. I think it can also handle the older Windows NT if that is a requirement. There are lots of architectures supported with a single code base. But for many the Pascal language is just to be laughed upon. Well, I make fast money using it and laugh from JavaScript.
• eviks 6mo ago
  > knew I wanted to use the latest and greatest first-party foundation. That meant writing a WinUI 3 app, using the Windows App SDK No it doesn't? That's "the latest", but not "the greatest", and as "a Windows guy" you should know both the meme "wait until sp1" and the principle behind that about the inverse relationship between the two factors in that phrase > what is the point of using Microsoft’s latest and greatest, if half your code is just interop goop to get at the old APIs? Good point! Don't, wait until they realize their newest toy isn't popular enough, throw it away and create a new one - use that instead! > 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 No one using anything of theirs would ever think that!
• jayde2767 6mo ago
  "Left behind", the most common phrase used when describing Windows Native programming...at least anecdotally.