This is a good overview of some of the options, but the author’s specific requirements push it in a specific direction that eliminates a lot of options.
Specifically, the requirement for completely custom GUI styling without writing his own render functions means it’s really a task of selecting easy, customizable GUI libraries rather than generic GUI work.
The requirements to be self-contained executables and under a 40MB limit also rule out a lot of options. The author admits that Qt could have met these requirements but the open-source licensing part wasn’t compatible with his goals and he didn’t want to pay for a license.
If you relax the requirements to tolerate some dependencies, allow larger download sizes, or to simply use built-in Windows GUI controls the situation is very different.
For writing a lightweight, completely custom GUI with no external dependencies and permissive licensing I could have guessed ImGui would be the answer before I started reading.
If instead of insisting on custom UI styling the author just used the system UI, they could probably build a pretty straightforward Windows application. It’s the scourge of “brand identity” that has people thinking graphical applications are hard.
Same on the Mac: If you want to build a Mac application, your best bet will be AppKit or SwiftUI and using system controls. And when the OS updates your application will either update with it, or need only minor tweaks and a rebuild to look good.
This indeed. Custom UI widgets for Windows apps are really not necessary most of the time, and fitting in with the system theme is all you ought to aim for, most of the time.
There are exceptions, for very rich dense UI, for UIs that need to be cross-platform, but if you're writing a Windows app, it should look and feel like a Windows app.
Most applications would be fine with a button on Windows looking like a Windows button, a button on Mac looking like a Mac button, a button on Android looking like a Material Design button and a button on iPhone looking like a UIKit button.
You need consistency in the icons, layouts and concepts, but you don't need every widget to look exactly the same on every platform.
Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.
Is your app very large but not that large? (Slack/teams come to mind) I think you can go either way.
If you are smaller than that (hint: you are) then you should comply with the design language of the platform, even if that means somewhat large changes such as moving buttons from the left to the right. The likelihood that users are constantly using your app on a iphone and android is really low.
I disagree. I think the only apps where a custom UI make sense are games and I’m willing to accept highly specialized business apps that have their own conventions. Thinks like Blender, AutoCad, Logic, etc.
I’d still like to see them try to match a little, but they’re specialized enough I get that may be a better path.
Chrome? Facebook? Slack? Teams? No.
I’m not saying things need to look like MyFirstWin32App built with VB6 in 20 minutes.
But use the system controls and conventions. Custom colors and layouts can be fine. But if you want to make your own UI toolkit then make your own OS too and leave my computer alone.
> Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.
No app is more important than the OS, and certainly not Facebook (which has no business being an app in the first place). I made a choice when I got the OS, and I like developers respecting it and not chase the fad of the day with poor approximations of the native widgets (text fields that do not support standard shortcuts, buttons that do not behave as they should, labels that do not support accessibility features, the list could go on). Even huge apps like Photoshop or Office get this wrong everywhere.
I definitely agree on the default (use the native toolkit), but there are no applications big enough to get their own behaviour. Open Source or hobby applications get a pass if the UI is a bit wonky, but that’s about it.
> Does Microsoft themselves build their apps this way?
I'm not sure anyone could really answer this question considering how fast Microsoft's various silos pinball between UI conventions. All of them are (I would hope) based on various iterations of their own internal tooling, but looking from Windows 7 to 8, 10, and then 11, you get such stark differences in UI language that you feel like you're looking at competing products.
That being said, I would personally very much prefer apps that are built to mimic the system they are a part of. One of the worst sins of that one, IMO, being iTunes on Windows which has always been and continues to be a flaming dumpster fire for a number of reasons, but most especially it's UI. It is a Mac app that is parked in Windows. It looks like a Mac app, it operates like a Mac app, it's UI conventions are that of the Mac, with the one major difference being they stuffed the window controls in the window in an incredibly slapdash way to account for Windows not having the system bar.
But yeah, for any marketing people here, I have not once nor will I ever give a single molecule of a shit about your brand identity. Make your software good. Ideally make it mesh with the system it's in. I couldn't fucking care less what color everything is.
I, for one, miss customized installers. We've kind of lost out on those what with the move to digital distribution.
Gone are the days of my friend accidentally having his volume cranked when he inserted the Red Alert 2 disc, not knowing it would blast out "WARINING! Military Software Detected!"
My experience with SwiftUI on the Mac is that it still needs a lot of work. Documentation is poor. Performance can be bad if you do things in a straightforward way. Supporting older versions of the OS is quite painful etc.
Documentation remains the number one reason I personally don't make Android apps and why electron/web apps are the way to go for most GUI apps these days.
I recently built a small app using SwiftUI. It was my first, and pretty simple.
The documentation was absolutely maddening.. Half the time the Apple docs referred to a previous version. “Do this thing in XCode” often included screenshots of UIs that don’t exist in the current version of XCode. Examples I found on Stackoverflow or random blogs were usually no longer applicable.
It felt like magic when it worked, all those VStack HStack nestings, but the annoyance of finding my way there made me seriously doubt whether I’d build a big app with SwifUI, especially if I wasn’t working alone.
Thanks for the follow-up. These types of anec-data are the best part of HN.
> It felt like magic when it worked, all those VStack HStack nestings
I know the feeling from Qt. I think Gtk and many other GUI toolkits use the equivalent of VStack and HStack to make resizable GUIs. Some GUI toolkits try to avoid this problem by using a grid layout, but it is more rare.
EDIT
> made me seriously doubt whether I’d build a big app with SwiftUI
From your experience, what GUI toolkit would you prefer? And, it would help to know what is your target UI platform.
I don’t have much app experience, I’m mostly a back-end guy trying to build some prototypes and (hopefully) one product.
I’m not in a position to give anyone advice, but I’d love to find SwiftUI but cross-platform and usable from anything other than XCode (well maybe not Ed…) and native GUI and a pony.
For my product I need to support Mac, Windows and eventually iOS/iPadOS. For prototypes iOS is enough. I don’t mind learning new languages for this, but ideally there would be some advantage in knowing the language itself. I’ve been looking at lots of frameworks over the past month.
The most tempting thing so far is Flutter, but I have nagging doubts: because it’s not native UI, I worry about that being a no-go for some large customer down the road, and also about alienating power users. I looked at React Native but it’s not very good for desktop yet as far as I could tell (and the demo app from the documentation doesn’t work, which is a bad sign). Which is too bad because I was impressed with Expo, if I just needed phones I’d probably use that. I looked at Avalonia but it has the opposite problem.
Today I’m looking at Tauri for the Nth time: at least I could improve my Rust, and it seems to have momentum. Doing the UI in a web view is kinda sad, though, after trying SwiftUI.
Just building multiple apps is not realistic, I’m a solo dev and want to get this to market in my lifetime, and it only makes sense if I have both Mac and Windows.
Very happy to hear recommendations from people who have done this!
If you really want native look and feel then really your only choice is to use the native toolkits.
I'm not convinced many users care that much about this though. They spend most of their day using apps that don't use native controls and I think they're all pretty used to it by now.
I prototyped a bunch of different desktop toolkits and I think that today Flutter is by far the most polished and mature. I've had overall a very positive experience using it for my music app:
The threat of Google canceling it is real though. I suppose if that happens I'll switch to Tauri or just give up on Windows and Android and do SwiftUI. My experiences with SwiftUI to this point have not been very positive though.
Kotlin Multiplatform might also be an option at some point but it doesn't seem that close today. Unfortunately it seems like none of the os vendors are making their desktop APIs a priority these days.
Thanks, I will have a look at that. Serendipitously, I'm in the market for a new music player!
Yeah the Google risk... seems like they came out strong in support of Flutter at their last dev conference, but at the same time it does _not_ look like they're using it for their main apps.
Without expressing an opinion on Flutter as such, it's worth remembering that Google is a big enough organisation that even -some- internal apps being built using it is quite a commitment, and it not having spread further internally could easily be a social or political rather than a technical issue.
I don't think it it's a technical issue. On a technical level Flutter is mostly great. But Google has been doing aggressive cost cutting lately and not having Flutter in use in that many apps makes it more vulnerable.
Did you do cross-platform and if so, did you use the same UI style for everything?
Today I was making a list of reasons/excuses for using Material Design on Mac… which I guess would make some people mad, but it might work for an enterprise product.
Yes cross platform and the same style. I don't think this matters much to users today. They're used to it.
That said I did do a fair bit of my own theming. The Flutter Material widgets are actually pretty customizable and I'm not a big fan of vanilla Material.
Dear ImGui is for development/debug tools, not an UI for the end-user. It's great for small projects as long as you don't care about accessibility, or proper keyboard support, or adherence to standard UI conventions, or support for devices without GPUs, proper font rendering, etc. ...
Most games don't use ImGUI, though. Like the parent commenter said, it's useful for debugging, but the actual in-game UI—HUD, inventory, map, etc—is usually rendered by yet another middleware framework like Scaleform, or something that the engine provides (Unreal or Unity).
This is true. There is a reason why Scaleform made its way to become a popular gaming UI framework even though many of its weakness. The most important focus in game UI framework should be on tools and pipelines for artists/designers and this is usually not up to engineering decisions. I won't say that using ImGUI for game is impossible, but there might be lots of tooling works ahead for production game development.
Nuklear is sometimes used. Anyhow, I do know of some game engines created and used by a (very large) game studio that uses ImGUI. I won't say anything else though :)
There is also furnace[0] and mmlgui[1]. Which are recently developed programs that people have been using to create chiptune music for retro video game consoles. Including being used by Yuzo Koshiro[2].
imgui offers incredible development speed. And I've used it many times with great success. It's unorthodox yes (and there's a long-open bug I won't talk about again) but it's dear to my heart. It's like MFC on steroids: You don't have to leave C++.
But yeah at least a few of those caveats remain. Although keyboard navigation and font rendering have quite a bit of support.
Because adding a text is just a imgui::text("abc") function call. And a button is just an if(imgui::button("click me")) do_something() statement. There is no other language involved, no markup, no gui editor. Just direct code and highly hackable to make this extend to unexpected lengths.
To add to this, I find it easier to have a simple while loop that renders the screen, fetching variable data on-the-fly, etc. It is rather pleasing to the eye to understand the layout with IM interfaces, etc.
Comparing this to (something like) WPF, you create XAML files, with either or combination of ViewModels and back-end code to "bind" and can get complicated quickly. I guess the only exception to this is if you have commited to WPF non-stop for many months. However, with IM interfaces, its easy to get going (imo)
Excellent reply. I did not consider international keyboards when I writing my reply. And gaming companies are definitely targeting international markets in 2024!
Agree. "Single executable" combined with "less than 40mb" is just looking for trouble for what the author is trying to do. If you want to do win32, go ahead and give up styling. Otherwise, make compromises. I think many of these are excellent choices chosen by many programs that I use, it's the author's stringent requirements and unrealistic expectations that is holding back.
This comment makes me feel like I live on a different planet.
In 1999, I built a completely custom Win32 GUI for a (brandable) chat application - that was the product the company I worked for was selling.
Pure C and C++. It was a 32-bit app, not 64 bits. And we felt bad for it being 250KB single executable (skin included in resource section) and not “150KB or less” as was our initial target. But making it accessible and fully skinnable/themable/l10n/i18n did add quite a bit which we hadn’t realized when thinking 150KB was realistic. But it’s not like we resorted to any crazy tricks; that was just the stripped linker output.
It was still a reasonable download at the dominant dial up internet at the time (28.8Kbps IIRC)
Sure, modern tools add a lot of cruft that you’d have to work hard to reduce, but 40MB. Oh man.
It is perfectly fine to build a 150KB or less executable today. But then OP decided they don't want to write paint functions for custom GUI and insist on finding a library to do so, I guess that's not what you did in 1999, right?
I actually used FLTK for the first iteration; The theming support it had at the time was not sufficient, though, and the i18n story non existent (that was before even 1.0, versions were still labeled by dates).
So, because pervasive theming/branding was a hard requirement, and i18n a softer one (every skin has to only support one locale), i had to abandon FLTK. But FLTK did spoil me by providing seamless flicker free double buffering out of the box, which I insisted on implementing in our gui.
For those of you who don’t remember - Win32 flickered badly on almost all screen updates, window resizes, etc — I think that was generally true of most apps until 2010 or so. FLTK was essentially the only GUI toolkit at the time (1999) that had no flicker out of the box.
My app is around 500 KB (not megabytes) and it supports dark mode (see https://www.abareplace.com/). So this is definitely possible without using Electron or bloated GUI libraries.
IMO, every media player since Winamp 2.x has been largely a step _backwards_ in pretty much every metric one could put forth. It was light-weight, using minimal CPU & RAM. It was skinable. It was reliable. It had great plugin support. I don't recall it leaking memory, either. I basically had it set to auto run on login on my PC. I never closed it. Didn't need to. I had _only_ 32MB of RAM on that computer.
Qt makes such amazing apps. I love KDE and the apps they spawned like Kate, KDEnlive, Krita.. It's no wonder their apps are so popular on Linux and windows alike. Unlike GTK apps even though it does have bindings for Windows.
Well that's the killer right there. I too think it's way too painful to write Windows UI, especially if you want to stay away from Electron (which you should in almost all cases), but refusing to pay money for good software is going to severely hamper your goals in 99% of cases.
Is this really still true though? VS Code and Slack are all quite polished and give me no issues as a user. Not sure what else I'd consider to build something similar.
I might understand polished, but no issues sounds odd. What about the abysmal performance?
Also most folks building things do not have the resources that Microsoft has, so I believe VSCode is not a good represantative of most Electron software.
If you’re on windows and want a “standard” guy, either use the .net GUI or Qt , if you want completely custom and willing to do the work use QML or ImGui (or variant like eGUI)
Nah, it is so bad, that on BUILD 2024, they have brought back first level status to WPF.
No one burned with WinRT history since Windows 8, is ever touching WinUI, unless they are Microsoft employees on WinDev, or companies with sunken costs trying to keep their products around.
Win UI 3 is the worst kind of improvement because there's arbitrary equivalence between WPF concepts and WinUI concepts, not a 1:1 equivalence. WPF as the mature stable model should be gospel; you don't re-write the gospel. Yet Microsoft feels they should re-write this gospel because... it aligns with the vision (???). Both use XAML, but the concept of DataContext is substantially changed, the concept of bindings is substantially changed, etc. Why make every XAML attribute ever-so-slightly different? Are those changes really an improvement? A lexical improvement? A performance improvement? Or just baggage and overhead to learn?
Compare Microsoft to OpenGL. Boromir says "one does not simply change the OpenGL API..." Microsoft does not have nor ever had OpenGL level of API with their UI frameworks. I guess you could say WPF is maturity in age only but doesn't represent conceptual maturity.
With the differences, you basically throw away all the knowledge of WPF to restart in WinUI, and with poor documentation. The documentation is there, i.e. the "what" but the docs should be primarily "the why and how"; how to map WPF concepts to WinUI3, which is arguably the more critical documentation to provide, and currently pitifully poorly documented.
Doubly so because it would help indicate a measure of feature equivalence; does WinUI 3 currently represent feature equivalence to WPF? Has XAML Behaviors been integrated as a member of the API?
Except it's still missing a lot of controls, further development and bug fixes are practically at a standstill, and despite what TFA says, there is no visual designer support (which is a dealbreaker for many multidisciplinary teams).
As someone currently involved in switching our app from MFC, I really want to like MFC, but Microsoft's absolutely addled management of the whole thing is making it really difficult.
Title is "Writing GUI apps for windows is painful", and then the author slaps on a bunch of bullshit constraints but pretends to be covering the general case. Sorry dude, if you want to do that then change the title to something appropriate like "Writing small, custom styled GUI apps for windows is painful". Otherwise this is bait and switch.
Implicit (for me anyway) in the title is that you are talking about vanilla GUI apps. Writing vanilla Windows GUI Apps is trivial and there are a bunch of tools that handle this extremely well. The article covers many of them but chooses to disqualify them for reasons.
Then we have ImGui as the tool of choice, but now this is qualified as only for "simple apps". Really? After all the fuss about constraints not being met? A bit of cognitive dissonance here I think.
More complex functionality things can get difficult but often even these are handled depending on the tools.
For vanilla dev the clear winner in terms of productivity has to be WinForms. Or if you can live with the clunky IDE - Lazarus. (You're allowed to replace with your own favorites.)
The real challenge is not writing GUI apps for windows, but rather is in writing cross platform apps.
> This is a good overview of some of the options, but the author’s specific requirements push it in a specific direction that eliminates a lot of options.
The blogger sounds like they put up a bunch of arbitrary constraints that in normal circumstances wouldn't even be issues.
In the process it's those arbitrary whimsical choices that reject the very obvious choices along with any happy path.
For example, it's baffling that there are already a few FLOSS forks of Qt out there, but the blogger failed to cover them. If the author likes Qt so much, those would supposedly be the obvious choices. But no.
Once again, you are left out of options if you go out of your way to avoid each and any option.
Not true at all. The LGPL does not specify anything about mode of linking or anything like that.
What the LGPL requires is that the end user be able to take the source code for the LGPL part, modify it, recompile it, and then replace the functionality in your binary provided by that part with their new part.
Obviously with dynamic linking this is almist trivial, the end user replaces the so or DLL and done.
With normal static linking, it's only a bit harder. If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.
> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.
This is super clever, I love it! Does any software actually do this?
> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.
Do you need to ship it alongside or produce it on request or link to where they can fetch it? It's not like you need to ship source code alongside either for GPL binaries.
Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.
You’re not getting a size reduction if you maintain a library boundary, though. What you’re doing is isomorphic to dynamically linking except the app code is in the library and the library code is in the main binary.
I never understood the need for a single executable on windows when folders, zip files, and 100% free installers exist if you don’t like zip files. Also nearly all of the gui kits he’s shooting down have ways to build custom components if that’s what you want to do.
None of these help you if you are dealing with users that move executables for convenient access or think updating the sofware just involves dragging and dropping the new executable into the existing installation folder. Customer support had countless stories like that.
Does using something like APE by jart work? It's a single executable that's also a zipfile. (I assume a replaceable .dll inside the archive is LGPL compliant) I know it's a bit of a tangent, but on platforms like macos the "apps" are all directories with the .app extension, and that doesn't seem to cause issues.
No need for an installer when it's just one file you can run anywhere. And folders/zips are way too hard for the average user. Ask me how I know. My partner gave up an entire game platform because it was delivered as a .7z file they could not figure out.
True, but they are optional and are not the parts you need to create a GUI as per the requirements in the OP. I assume CopperSpice does not include these components.
Yeah, I can confirm that writing windows GUI apps is not at all painful for me. I still use Windows Forms in .NET 4.8 and my executables are < 1mb, Visual Studio's form designer is very easy to use, you can subclass all the .NET UI controls and customize them however you want. There's always been accessibility and even support for high DPI.
.NET 4.8 is the last .NET to be bundled with Windows. It's a legacy stack, but it exists on every Windows >= 10 so it is a legacy stack that makes deployables easy (just assume it is installed). (.NET 4.8 is the new VB6.)
With .NET 9 right around the corner, how far behind the legacy stack is only increases.
.NET > 5 will never be installed out of the box on Windows PCs. The trade offs to that concession however are: cross-platform support, better container support, easier side-by-side installs support ("portable" installs). .NET > 7 can do an admirable job AOT compiling single-file applications. For a GUI app you probably aren't going to easily get that single-file < 40MBs yet today, but it's going to be truly self-contained and generally don't need a lot of specific OSes or things installed at the OS level. Each recent version of .NET has been working to improve its single-file publishing and there may be advances to come.
A nice thing about .Net Framework 4.8 is that they finally finished it! No more update treadmill and dicking around dealing with what versions are installed or how to configure your application to use whatever different versions. Just target that and forget about it.
40MB seems like a weird requirement. If it’s under 1GB, I don’t think most people really care any more about executable size. Memory usage is still relevant, but 1GB is going to be less than 1% of disk usage for almost everyone.
1GB for each app accumulates really quickly. 40MB is really low, but I wouldn’t be happy with 1GB per app personally. Anything below 500-600MB is fine.
I want my disk space for large medias, not for a desktop app
I've gone through the same process of evaluating x-platform alternatives and I can now understand why Electron is so popular.
I mean, you do have the unreasonable bundle size, but other than that you can make really good looking applications using the same tools you can use to make web sites for both desktop and mobile.
I've been eyeing https://neutralino.js.org/ since if I'm going to make the app render right on browsers then relying on the same code via webviews likely isn't (much) more portability effort.
I have a very low opinion of developers who decry having to pay for a commercial licence for otherwise LGPL licensed software libraries. They expect to be paid for their work, and ensure that by creating closed source software. That's fair enough. Yet, the devs that solved the actually difficult parts of creating a UI library have to be utter saints who freely bestow a gift of code upon the world.
I think his complaint is not that he has to pay money per se, but having to pay several thousand dollars. That's a bit much for an independent developer.
I have little sympathy for that kind of argument, imagine a carpenter complaining that they have to buy wood and nails. Besides, a Qt license for small businesses is nowhere near thousands of dollars. Only in software development do we expect quality tools to be given to us free of charge with no strings attached.
Qt for Application Development Professional (ADP) is 3460 €/Year.
If you're making something which you sell for $50 or so you'd need 100 sales per year to just pay for the development environment. That also assumes that it took you less than a year to make said product.
I guess that is just one of the many risks you have to take if your trying to build a business. A couple of hundred dollars in licensing fees are not going to sink your product. For a side project that you don't expect to make any money it might be too much, but in that case you could just as well open source the project.
It's especially hard when the application you're building isn't yet proven. As there's no guarantee that it will get any sales, let alone enough to cover the Commercial Qt expenses.
Qt is amazing, so if your requirements are so strict in terms of space and you know/like Qt, investing in the license, or make the product open source, shouldn't be an issue here.
Agreed. Also didn't get why he felt complying with the terms of the LGPL for a statically-linked .exe would be so much of a problem. Just put the object files and build script in a zip file, and upload it to the same webserver where you plan to put the program. Add a line in the "About" dialog (or whatever) pointing to it. Done.
Whilst I don't understand the users who are hell bent on having a single-executable work, if you have users who are hell bent on using but a single executable, you have to meet them where they're at.
No, it makes perfect sense to complain about paid software libraries because it inevitably makes getting to them a huge pain in the ass and that causes folks who just want to easily give the library a try every reason to go try something else. Then as a result the ecosystem of apps using sad framework begins to stagnate.
Yes, closed source libraries are a pain to work with. This is why I like the GPL/Commercial dual licensing model. You can try it out for as long as you like, have full access to the source code and can even create commercial software for free. You are only required to pay for a license if you want to create closed source software. I consider this an absolutely fair deal, yet the blog author seems to take issue with that which is what I am criticizing.
That’s fair in theory, but it really feels that they’ve made it more difficult to find the open source version of Qt last I checked. I haven’t tried to use it in a while, but I recall last time I tried I just gave up.
Unfortunately they do and they really try to scare you away with the GPL boogeyman.
It is a fair criticism. I would recommend to ignore the installer entirely and rely on a package manger like vcpkg, conan, apt, or brew instead.
While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret.
Also the single exe deployment, while convenient at times, is perhaps not worth the hassle in this scenario. Using a packager like Velopack (squirrel) makes it a single exe to distribute and as an added bonus makes it self updating. That it has two or more files on disk when installed seems like a good tradeoff.
Windows is the worst platform to develop desktop apps for, apart from all the others.
> While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret.
What I find the most mind-numbing thing about the blog post is the way WinUI3 was excluded. WinUI3 looks like an exact match for the blogger's most critical requirements, specially the customization thing, and there is absolutely no better way to target Windows than Microsoft's official GUI offering, but somehow that one is rejected? Absurd.
WinUI3 is a can of worms that’s becoming palatable only with .NET 8 (and soon 9). In a normal configuration, you have to bring 500MB of dependencies with you, or ask the user to install a redistributable. You also need the user to install .NET 8, or bring said 0.5GB with you.
WinUI3 can be used in unpackaged apps (I.e.: not appx) but has a few random caveats that just don’t work; random APIs that have a footnote of “oh this doesn’t work in unpackaged apps” or “works in unpackaged apps but only in .NET Preview something-something”.
.NET 8 fixes a lot of this by adding AOT compilation and single-binary releases, but it’s still fairly large. .NET 9 then improves culling of unused framework code from your published file, and also adds WPF -> WinUI3 theming support.
Source: my repeated attempts to rewrite our product’s UI in WinUI3 (from WPF on .NET Framework 3.5) several times.
I don't understand why Microsoft puts it on the user/dev to make sure their own dependencies and "VC redistributables" are installed.
Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library.
Feel I always hit a roadblock when setting up a new PC where one of the things needs that but the dev didn't provide it and I have to get it myself. Which feels weird when it's an official MS thing from their official dev tools.
Microsoft's solution to DLL hell was installing lots of DLLs side-by-side. The problem with WinUI and VC redistributables is that we've now got a combinatorial explosion of them and teaching an installer to know and understand the complex network of dependencies is a lot of work.
Microsoft's intended solution to this was to write one last Installer platform to try to rule them all. That's where AppX and MSIX installers came from. Unfortunately for us all, that Installer platform was synonymous with the Windows Store/Microsoft Store for just long enough that everyone assumes that is all that AppX/MSIX were intended to be. Today MSIX supports everything you want to do in a Win32 application, plus all the Dependency Fu of getting a WinUI application correctly installed. Just about the only left that you can't install directly in an MSIX is kernel-level drivers and even then there are options depending on your hardware vendor relationship with Microsoft.
The article dismisses MSIX packaging out of hand, but given it is still referred to as AppX packaging in the article, the author might not be aware of how much MSIX packaging has advanced in a bunch of years and still makes some assumptions of MSIX limitations based on early Store-intended AppX restrictions.
The app manifest could state "I need this runtime installed". The OS can know whether it is already installed or not. The OS also knows whether it is internet connected or not. If a runtime that isn't installed is needed and internet connectivity isn't available, the OS could state that, with information about how to procure the runtime manually.
That would stop people that have copied thr application from a pendrive in an air gapped system, that's true. One could make the case that someone meeting all of those requirements for would be technically minded enough to figure it out.
This wouldn't help developers who want to distribute a small application that won't ever require a download, but would be an improvement for anyone already distributing .Net applications over the web.
The OS presumably also knows where I should get it from as the same company hosts the installer as ships the OS. Yet IIRC the error is just an obtuse thing complaining a DLL isn't there and through googling and hopefully finding your way to Microsoft.com not some malware site you have to find the installer yourself.
Mild annoyance for someone with 28 years Windows experience, complete roadblock or malware vector for someone who just wants to use a computer rather than understand a computer.
What kind of build settings lead to 500 MiB binaries? I struggle to imagine something that could make the toolchain to emit such a large binary save for select degenerate cases of runaway generic specialization when you AOT compile an SDK that combines LINQ with 2102718201 enum types, all of which get their own set of generic instantiations for every internal iterator within LINQ - that's a known issue that is fixed by enabling identical method folding in ILC, the worst offender used to be Kiota OpenAPI generator causing this, but thanks to tireless work by Filip Navara that was fixed there.
In general, there are quite a few knobs for configuring how exactly you would like to have your application published. This is also an area of active improvement with each new release as you noted. It is very worth it to look into further build configuration nonetheless. If you still face an issue with "this surely shouldn't take this much space", it might be a good idea to submit it to either https://github.com/dotnet/runtime or to the repo of the GUI framework depending on where you think the fault lies - without feedback it's difficult to know if there is an area that needs improvement or a known improvement opportunity that has demand.
If you want to be "normal", or at least follow the Microsoft semi blessed path, and make an appx, that does not include WinUI3. The user installs it, and in the process pulls down WinUI3 (also an appx) if it is not already installed. It's only if you really insist on "self-contained" that this problem arises.
I say semi-blessed because of course Microsoft aren't really committed to WinUI3 and barely any of their own apps use it.
Self-contained/single-file mode is compatible with trimming and benefits from the work done to improve AOT story. As AOT binaries get smaller and ILLink's analysis gets smarter, the single-file trimmed binaries will see a part of such improvements.
The issue is that many GUI frameworks are not AOT-incompatible per se but rather trim-incompatible as they rely on reflection that is done in a way that is totally opaque to ILLink save for rooting everything.
You can try the following publish option anyway, and in many instances it "just works" (assuming .NET 8 SDK):
dotnet publish -o out -p:PublishSingleFile=true -p:PublishTrimmed=true
Note: trimming was introduced in .NET 6, and NativeAOT was initially introduced in 7, so it had seen quite a bit of work to mature and improve by the time 8 shipped.
Some of the issue is he has outdated understanding of AppX packages (MSIX). You can use all of Win32 from an MSIX package, and all of WinRT, and WinUI3 etc. It's actually the other way around: there are some Win32 APIs that only work if your app is packaged.
From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code)."
I don't understand what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it.
But why even use C++ for the front end if it’s going to be .NET? Managed C++ is mostly useful as a shim, not as a platform language. It’s not really an alternative to C# on the .NET runtime but just some C++ extensions for interop with it.
If you make a WPF/WinForms frontend then that should be the exe entry point, and that would likely be managed. Then your business logic would be the auxiliary DLL (which can be embedded into the managed exe). There could be a layer of C++/CLI between these to layers (C# front end and native backend) because it would make the interop a bit easier than having to do C-style interop.
Actually I find it much easier to write C++/CLI, than getting right all P/Invoke marshaling, specially if COM is also part of the picture.
Also C++/CLI can also generate native code when specific code patters are used, that is why there are some compiler flags to disable it, and such assemblies are considered unsafe.
> I don't understand what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it.
I don't think the author is talking about interop here, but rather the fact that GUI front-end code written in C++/CLI still ends up being managed rather than compiled to native code. I suppose the author insists on the front-end executable being nothing but a PE x86-64 binary without any runtime/GC embedded in it, pure native code.
Same here. People are confused because the author gave two options:
1. Bundle the .dll as a resource into the app and make it extract it to some temporary folder, then use P/Invoke and call the compiled .dll from within the C#/.NET app.
2. Use C++/CLI.
And then a single "problem" paragraph that didn't make it clear which problems go with which approach.
Reading many of these comments makes me realise that the whole premise is flawed. I "vote" to rename this blog post as:
> Writing GUI apps for Windows is painful when requirements are unrealistic
They should try to target .NET Framework 3.5 using WinForms. That is my best suggestion, as all recent versions of Windows will have this installed (at least).
Not limited to CLI (even at release in .NET 7 it was possible to use it with ASP.NET Core with limitations and there were custom templates to make it work with some GUI framework I think, and MonoGame already worked partially), certainly not in .NET 8. I’m not sure about WinUI 3 itself, but a lot of things today are AOT compatible.
And naturally single-file + trimmed works almost everywhere, in some situations requiring to add attribute annotations for un-analyzable reflection usage patterns.
"Single file" has the annoying property that it unpacks all your assemblies at runtime and dumps them in a temporary directory. There's no good reason it couldn't byte-load them directly out of the executable instead.
Do you mean IncludeNativeLibrariesForSelfExtract attribute? This is a related but still separate feature. If you mean the managed assembles, then it works differently:
"Only managed DLLs are bundled with the app into a single executable. When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder. With this approach, the managed binaries are embedded in the single file bundle, but the native binaries of the core runtime itself are separate files."
For """embedding""" native dependencies into the binary without self-extract, you can't really do that, the closest alternative is statically linking them into AOT compilation instead (but that gets tricky with large dependencies).
No go for net 4.6 which is installed on every currently supported Windows version back to the original Win10 released almost a decade ago.
There are still people running Win 7 but I wouldn't worry about that group having a streamlined experience. With 4.6 they can still install the runtime manually.
4.6 instead of 4.8 because 4.6 comes preinstalled with any Windows (Any supported Windows that is, i.e. Win10/11 or equivalent server), so from the user's perspective it will be a no-dependency app, just like a Win32 app.
Anyone reading this thread will surely roll their eyes and move on to a different solution. Event the people who recommend this stuff to others get confused about what the fuck is even happening in the .NET ecosystem.
It was pretty simple up until the whole netcore fork and netstandard confusion. Then it was confusing for a number of years. And now it's actually pretty simple again.
The naming of ".NET" and ".NET Framework" is confusing as hell. But basically Microsoft is hellbent on launching something completely new and having that take over the .NET name, even if it means years of confusion.
The reason why I suggested 3.5 was to include a long line of compatibility with older versions of Windows. And, correct me if wrong, a binary compiled with / targeting 3.5 will still run on 4.8
Sciter desperately needs an evangelist who can reply and help people with their problems and just in general provide support and work on the ecosystem. I think from what I remember from indiehackers you are not there yet to be able to afford it but we desperately need that.
Even paying pravic to keep the libraries for different languages up to date would be of great help.
Mr. Yuri (Pravic) has his own agenda these days. As far as I know creation of Go, Rust and Python backends for Sciter was a method for him to determine best frontend technology for his organization.
If someone wants to take care about Go, Rust and Python wrappers - let me know.
I'm working on a GUI toolkit that should match the requirements: Slint - https://slint.dev
Can be compiled statically in a single .exe that is smaller than 40M. Has a license that allow proprietary on desktop for free. Has dark/light styles. Even comes with a (work in progress) drag and drop WYSISYG editor.
Where did the idea come from that starting with a 40MB exe is small? That's completely outrageous. You could embed all of python, tk, fltk, wxwidgets and pyqt and still not be close to 40MB.
FLTK static binaries start at 100KB, win32 binaries can start at 1KB, Juce is about 2MB.
Using GLFW or SDL for an openGL window then using IMGUI would start at a few hundred kilobytes.
What are you doing in there that makes your binaries 100x times as big and why would this be a selling point?
OP said less than 40MB. You can build Slint binaries targeting embedded devices. So a few hundred KB for a small application. Still arguably too much space but gui frameworks like slint use a domain specific language that generates more verbose code than what a human would typically write. Probably in the interests of being generic.
Man, as a C# dev, I'd kill for a single exe output. The binary being only 40MB is an absolute fantasy.
We have a project at work, it's nothing crazy, mostly shuffling data from one pipe to another, maybe a few thousand lines of code. A true standalone build including dotnet is over 180MB. The build that relies on the system dotnet install is still over 50MB. It's not even a GUI, it's a background service.
Things on Windows have a bad habit of enormous binary bloat, I'm not sure why. I don't think the problem is near as bad on Linux in general, but I don't have enough experience with linux dev to really say
I deploy my asp.net site to Linux by building it as a self contained single file. Deploy services. Have a couple of WPF apps both self contained single file.
They all end up around 43-85mb. The services are smaller when trimming is applied at around 30mb.
Not a single project has ended up over 100mb but I can see that happening if you have a ton of nuget packages.
I don't know for certain but expect it comes from comparing solutions with those based on virtual machines like Java's. The requirements in the original article look like a corporate wish list.
I've been evaluating GUI frameworks for rewriting the editor of a cross platform (Mac Windows Linux and web) game editor I maintain, and this looks worth a shot, thanks for sharing here!
I want to move away from the ancient allegro GUI we use, and so far have evaluated ImGui, RmlUi, and Qt, but so far not totally sold on anything.
Thanks for the link, slint looks really interesting. As someone who's never made a GUI app would you consider it an "easy" task to make one using slink? Also I didn't see any results when searching the documentation for titlebar, is there any way to theme or change it using slink? TIA!
Wasn't it mentioned in an HN post or comment somewhat recently (like a few weeks ago)? I think I saw it then, and checked out the site and a few demos at the time.
There must be some confusion. This is not a web framework, it is a compiled framework with API for several programming languages (including C++) and no HTML/CSS.
From https://news.ycombinator.com/newsguidelines.html: "Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that.""
I realize project != article but the same point applies.
Note that if by following that guideline, your comment gets "shortened" to the empty string, the implication would be not to post. More helpful, though, would be to supply some specific information.
I acknowledge your comment, and I'm aware of the guidelines. I'm not the only one who questioned their response, so I don't feel particularly off balance here.
Oh I'm not saying your underlying point was wrong or bad! It's a question of how you express it. If it pattern-matches to a snarky internet dismissal, that makes it a bad HN comment even if the point is right. That's because readers will react more to the pattern-match than anything else.
It's even more important to follow the guidelines when your point is right, because if you don't, then you give readers an extra reason (e.g. snarky dismissal) to discredit the truth (i.e. your correct point) and this is a bad deal for everyone. Past explanations in case helpful: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor....
p.s. I don't think what you did was so bad and the length of my response here is just because I think you might find it interesting. It's not meant to pile on criticism.
Writing GUI apps is painful period, and it’s become more so not less in the last two decades.
Go back in an emulator some time and try Visual Studio or even old Borland from the 1990s. Point, click, add code, set style, and the result was not bad at all. The whole UI looked consistent too with uniform controls, shortcuts, etc.
Today UI apps use 100X more memory, are slower, and are harder to use with little to show for it in terms of improved functionality. The whole desktop is a disaster of conflicting designs and accessibility or uniformity are practically gone.
Mobile is kind of shocking too. Here was a chance to dump cruft from desktop and do things better but the result really is just as much of a pain in the arse if not more. Consistency is a little better but the developer experience is awful and of course unlike desktop you really can’t develop on the actual device. That adds another layer of shit.
It was stupid simple to get simple GUI apps up and running. More complicated apps were impossible. But, I think that's exactly what's missing in the Desktop GUI market right now. Webapps are incredibly easy to start apps with. You only need to know a few things and you can pick up the rest later as your app gets more complex. Modern desktop GUI systems are incredibly complicated, in comparison, just to open the window, let alone put text on the screen.
Larger memory footprints aren’t just from the GUI. There is a lot more functionality to deal with everywhere. Just handling modern security, encryption, and certificate checking stack can take up more space than entire executables from the early 90s.
I also have literally 100X more RAM now.
> are slower,
Im fairly certain everyone who says this has simply forgotten how slow mechanical hard drives were. I occasionally have to pull out a very old laptop, hope that it still boots, and do something on it. Everything is so painfully slow in ways I forgot about. It’s refreshing to return to my modern PC.
> and are harder to use with little to show for it in terms of improved functionality.
If you don’t think modern apps have more functionality, I don’t know what to tell you.
I assume OP means slower on like-for-like hardware, rather than slower when run on a PC from the 90s, but to be fair the WinForms/WPF component of old GUI's was very fast even on legacy hardware.
> There is a lot more functionality to deal with everywhere. Just handling modern security, encryption, and certificate checking stack can take up more space than entire executables from the early 90s.
What does this have to do with bloated GUIs?
> Im fairly certain everyone who says this has simply forgotten how slow mechanical hard drives were. I occasionally have to pull out a very old laptop, hope that it still boots, and do something on it. Everything is so painfully slow in ways I forgot about. It’s refreshing to return to my modern PC.
I remember 98/XP running circles on mechanical harddrives compared to modern PCs on ultra fast SSDs. The fact that despite thousand times faster hardware we have slower performance is disgusting.
> If you don’t think modern apps have more functionality, I don’t know what to tell you.
Care to provide an example what modern applications have that older ones lack? Except for always—on connection and artificial bullshit imposed by modern OSs.
> Im fairly certain everyone who says this has simply forgotten how slow mechanical hard drives were.
Absolutely, but I would go even further with this. I can't prove it, but I would bet a lot of money that Windows 10+ has made using a spinning disk even slower. I would guess optimizations around disk access were entirely different in the XP era compared to now, when it is assumed everyone has an SSD.
Anyway, I had an old laptop that ran like absolutely dog shit. I put an SSD into it and it magically became usable again.
+ "portable" (single exe with no automatic unzipping of dlls or anything)
+ commercial and unwilling to redistribute compiled object files (which together with the "portable" requirement, means no LGPL)
+ dark mode
Windows GUI apps is painful. Drop any one of these requirements and there are good established options.
Specifically I think most "portable" applications use win32 because, usually, portable => small, simple application where functionality is more important than dark mode or other styling ability.
> Windows GUI apps is painful. Drop any one of these requirements and there are good established options.
The "portable" one is not a hard requirement. It's a whimsical self-imposed constraint, which makes as much sense as complaining that you can't stand on your right foot on Tuesdays. All installer toolkits released in over two decades support deploying arbitrary components. Is this not a solved problem?
WinUI3 supports dark mode/theming out of the box along with fully customizable styling. It's as free as it gets. It's also Microsoft's official GUI framework for Windows. But the blogger rejects it because... Because what?
Well I remember one project where having the app small and portable or at least self-contained was a hard requirement. It involved an embedded device (ridiculously complex and over-engineered embedded device) that used customized USB flash sticks for user authentication, data transfer and firmware updates and configuration. The partitioning scheme of the update/configuration scheme meant that I had only about 16MB of free space on the windows-visible partition for a Windows GUI configuration application for the thing.
Originally I started writing it in MFC, but MFC is not exactly good match for something so trivial and all the abstractions meant for document-based applications were mostly in the way and I ended up doing it in Lazarus.
And those COM errors that just kill the process, bypassing C++, and .NET exception mechanisms? lovely!
No designer, manualy editing IDL files for XAML C++ bindings, without any kind of syntax highlighting or code completion, manually merging generated C++ code, even more lovely.
Using a Webview wrapping Bing Maps, instead of the native UWP map control, even better.
You can use dynamic_cast instead of reinterpret_cast. If the pointer isn't correct it would return null. A better solution is to subclass the widget, store a function pointer for the callback which takes the same class instead of an Fl_Widget, and call that in the callback:
https://github.com/MoAlyousef/FLMH
This uses a std::function for the captures but you can use a function pointer as well.
You can do that with straight win32 as well. Steve Gibson has a bunch of utilities and most of them are pretty tiny. His DNS Benchmark is one of the larger utilities at 169k.
I like win32 and you can get a lot smaller with win32, but there are a lot of things missing. FLTK has a lot of components, component layouts, fonts, file system stuff, networking, audio, an openGL context, image loading and it's cross platform.
I'm confused. What is "missing" from Win32? To be clear, I count all base DLLs included with Windows a "Win32". One thing I can think of from your list: component layouts. Resizable windows with component layout is awful in Win32.
> Writing the GUI part of the program should not take more time than the actual functionality
I don't understand why this is a rule. I mean, I don't know what the author is trying to build, but in general the GUI is the part that the users spends all of their time interacting with. I don't see why it would be a problem if a little more time was spent there.
Also, in my experience, writing UI code is usually more(!) work than writing the functionality underneath, because
a) styling / layouting has to be learnt from scratch (e.g. because of a proprietary language, e.g. QML or QWidgets for Qt)
b) you have to take care of every frikkin' single user interaction (which becomes worse the more dynamic and custom your UI is), and building proper accessibility is also no walk in the park
I had a similar struggle. I needed a truly cross-platform (Windows, Linux/Wayland, Mac, iOS, Android) GUI toolkit with rich controls library and reasonable theming. In fact, the only good option is QT and it's very hard to be productive with C++, it still lacks even basic features, like type deconstruction and ADTs/GADTs with exhaustiveness checks. QT bindings for other languages aren't mature enough.
Apart from QT, there is Avalonia, which is full of bugs. Linux support is remarkably bad.
Also there is Kotlin/Compose Multiplatform. It lacks good documentation, advanced controls and still full of bugs.
I was unable to find any good controls library for JS/TS, even paid ones (like Telerik and others) are pretty messy. So, Electron, Capacitor, React Native - they all assume a non-trivial effort to be put into even a very basic app.
Flutter feels extremely immature, and the strange popularity of global singletons makes it extremely hard to navigate even small codebases.
Are there serious issues with wxwidgets? When I was looking for this sort of things it was unglamorous, but had decent bindings with several languages and looked decent enough. I agree with your assessment of the other alternatives.
If I go with C++, I'll take QT, which has lot more extensive controls library and in fact allows me to be more productive than wxw.
Unfortunately, the main productivity limiter is C++ and that's something I really want to avoid. I've been writing C++ professionally for about 8 years so I think I can make such statements.
You need something else to run your electron app on mobiles. Ok, you take Capacitor, fine. Probably you'll take React (or something else) to manage your state. Great. You still need some UI toolkit. Literally all of them, even the paid ones, are pretty basic and dumb. So, most likely you'll have to make your UIs pretty basic and dumb, or reinvent the world and/or dig through tons of half-baked libraries which deprecate faster than you manage to integrate them.
Modern QT (with QML) has very low amount of the boilerplate, all the 7guis examples can be implemented with 20-80 LoCs and will run on all the platforms, although despite all the modernization efforts, C++ still feels dated and it's nearly impossible to be productive with it. The main issues are: lack of pattern-matching with type deconstruction, lack of ADTs/GADTs, lack of closed hierarchies, lack of exhaustiveness checks, lack of closed type hierarchy (no top/bottom), lack of typeclasses, lack of first-class functions (yes, while there is some syntactic sugar, it's just a sugar, e.g. you can't return two different lambdas depending on the template parameter from one template function).
I'm teaching myself the Win32 API for a future RE project, thinking that knowing it helps with the reverse engineering effort. I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet.
It actually take s a lot of work. The boilerplate code is OK but I never realized that showing strings on Windows is such a PIA. I have deep respect for anyone who wrote Windows GUI apps back in the late 80s -> early 90s before RAD is a thing.
As a side note. I recently got a book about WinG game programming on Windows 3.X/95. I remember back in the day the game Fury3, a fascinating 3d flight shooter game, was developed in WinG. It could be an interesting archeology project to develop something serious with WinG, the predecessor of DirectX.
I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet.
You could just use the standard Edit control for that. If you really want to do it manually, which I have done, it's less than ~300 lines of code for the whole app (including working scrollbars). The binary is less than 4k.
but I never realized that showing strings on Windows is such a PIA.
Are ExtTextOut and related functions all that hard to use? How much simpler do you think it could be?
IIRC WinG was basically a way to set up a GDI device context that corresponded to a frame buffer, so you could take your DOS SuperVGA code and run it under Windows, only redoing sound and input. It's been almost 30 years though. :)
You could do pretty decent games using GDI as long as you just wanted to blit some sprites and were very much adhering to what GDI would give you. If I remember correctly, all the examples in the "GameSDK sampler CD-ROM" (the original name of DirectX 1.0) were in fact not done with GameSDK or even with WinG, but straight GDI.
I think it was better and easier to set up a DIB, treat it as a double buffer of sorts and only use GDI to BitBlt it to screen.
Don't ask me how you do that, though it probably would not take me too much to page that stuff back into my brain by looking at the Microsoft Win32 manuals. Maybe CreateDIBSection? I still remember my kernel32.dll, but not GDI or User.
Anyway, what WinG did (and all it did) was speeding up the blitting part.
Yeah that's probably what it was back in the day. I recalled games run pretty slowly on Windows before WinG came out. Fury3 looked pretty slick, even in today.
> I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet.
> It actually take s a lot of work. The boilerplate code is OK but I never realized that showing strings on Windows is such a PIA. I have deep respect for anyone who wrote Windows GUI apps back in the late 80s -> early 90s before RAD is a thing.
The late 90s experience with VBA and the Visual Studio designer is, on the other hand, really good. As was the proprietary Borland Delphi experience.
You could do worse than try building an MFC app in VS to get something working and then reverse engineer the details out of that. Strings are not a pain provided you remember -DUNICODE and use wchar for everything (and the related functions).
I'm amazed Fury3 worked under WinG. I used WinG for some simple 2D games, but I don't think I would have tried texture-mapped 3D!
We wrote this game on DirectX 1.0. It was a pig because the game was designed to be all 2D sprites, but early in the project it became clear there wasn't enough RAM, so I wrote a 3D engine that integrated with the 2D backgrounds. The video cards of the day didn't like that shit, and there was no acceleration at the time.
All the DirectX code itself felt sluggish as games were coming from highly optimized bare-metal C/x86 to running on a multi-tasking OS through an API that was written in (probably) pretty unoptimized C++.
Wow that looks pretty slick. Now I know why early Windows don't have competitive games and why things like WinG and DirectX are pretty big. I think Carmack did not jump on the DirectX wagon until much later.
It's called "Dungeons of Discovery". The book includes a CD with resources to build a mini yet full blobber game. The CD also contains WinG.dll conveniently.
Apple and Microsoft underinvest in their widget toolkits. It’s especially damning for Apple since they spend the money to write numerous custom widgets (e.g., the widgets in their professional apps like Final Cut Pro and Logic Pro) but don’t upstream. Nobody is inspired by yet another implementation of button or tab widgets.
No idea about Apple, but I'd strongly disagree for Microsoft. In one way of speaking, they invest too much. WinUI3, like the article mentions has such a sordid history. It started as WPF, and WPF was (is) awesome. It's simple, clean, runs on a bunch of different platforms, doesn't have a zillion dependencies, has a great community, and is just all around pleasant to work with.
So naturally Microsoft decided to completely scrap it, replace it with a far less functioning successor, flop, and then repeat this process over and over til we get where we are today after WPF->UWP->WinUI2->WinUI3. And WinUI3 has also already been completely abandoned. Contrary to this article, it still doesn't even have a visual designer. The amount of time, energy, and money Microsoft has spent with all of these successors is going to be remarkable, just to keep throwing everything away and restarting.
Oh and while all of this was happening they've also been developing Xamarin, MAUI, and more that also all do pretty much the same thing - in completely incompatible ways, with a similar general trend of having the attention span, focus, and overall quality of a 13 year old ADHD boy, in a Japanese arcade, after 7 shots of espresso. This just isn't the sort of thing you could do without just completely absurd budgets and minimal concern about actually making something great. If they had instead just stuck to perpetually refining WPF, UI development on Windows would be a utopia today, and they probably would have saved an immense amount of money, or at least manhours.
A lot of the best people left MS. People forget that MS was so completely dominant that it attracted a lot of talented people who wanted to do big things. Since then the competition from the FANG companies have brain drained them, not helped by MS insistence on paying less than their peers, sure there is no state income tax but the company shouldn’t be trying to capture all of that difference.
The net effect is that not only are they not capable of building things as well as they used to, they can’t even maintain what they already have. And how would anyone go about fixing such a culture. I think that’s a big part of why MS has been so generous to OpenAI while also keeping them at arms length.
Inertia is incredibly powerful and big companies can remain successful for long after their technical competence dissipates.
> And WinUI3 has also already been completely abandoned.
I'm not sure where you got that impression, but WinUI3 is in almost all of Microsoft's software at this point. Admittedly a huge amount of it is embedded inside React Native, but WinUI3 seems to be the UI toolkit that has won and is still going strong. They announced a bunch of WinUI3 enhancements at BUILD even.
(One such announcement is a coming standard control for the sort of custom Windows Title Bar with a search box and branded logo and extra buttons that has become common in every first-party application from the Microsoft Store app to all of Office and many other places.)
> Contrary to this article, it still doesn't even have a visual designer.
Huh? Visual Studio has a visual designer for the WinUI 3 flavor of XAML. If you don't want to write XAML to back your UI they probably will never support a Visual Designer for you (ie, C# UI seems neat and maybe a bit more "functional programming", but I'd rather use XAML just to have the Visual Designer at least). Last I checked the XAML designer works just fine even in C++ projects targeting WinUI 3.
Visual Studio's designer really does not support WinUI 3. Try it! Hot reload also doesn't work worth anything. There's an ongoing issue/discussion on Github here [1] from 2021. There's also loads of fundamental issues like various controls causing replicable crashes with drag and drop, the community calls are disappearing, and more.
Sure, it is definitely very buggy, but the point is that it still exists and is useful to some extent. I was refuting the claim that there is *no* visual editor, not the claim that the visual editor we do have is maybe deficient and buggy.
Relatedly, I still think it is something of a shame that (Expression) Blend didn't survive to the modern era. A designer-focused XAML design tool that doesn't need a full Visual Studio install (nor the same sort of expensive VS license) and feels more like Firefly or Figma or whatever other designer-focused tool is current en vogue would be really handy in a lot of situations.
I don't think it is the only reason that designers tend to prefer HTML (and thus we use Electron or similar to placate the designers that think that "just copy and paste it from the design tool" works "well") over XAML, but it certainly doesn't help that there isn't a "XAML Figma" and it's a shame on multiple levels that Microsoft recognized that threat early on, built a solution, then got confused why they built it, confusingly merged it into Visual Studio licenses and installs, which lead to its sadly inevitable death just a few years before it would have been very helpful to have to send to some designers and stop getting HTML-only mockups.
To be clear I am saying that drag and drop operations do not work during runtime. The designer literally does not work at all, for WinUI 3, for reasons that are not at all clear, since Visual Studio had a 'native' designer for WinUI 2, as well as the weird disconnect with Blend as you mentioned.
I almost feel like you're mixing up WinUI 2 and 3, because the designer was kind of borky for WinUI 2 but did work, and was overall an okayish experience. But for WinUI 3 it's an entirely different game. Early on the messaging was that the designer would be "coming soon" (tm) and that people could just use hot reload in the interim, then at some point hot reload ended up completely broken as well, Microsoft gradually started withdrawing engagement with the community, and here I am saying it's been defacto abandoned.
The point of the designer is not just mock ups. At many (most?) small businesses and studios the developer/designer dichotomy doesn't exist. There's a reason lots of companies are still even using e.g. Winforms. A high functioning designer simply dramatically improves both productivity and quality.
While Apple could stand to improve some aspects of their UI toolkits (and you're right that private widgets have long been a frustration), I'd say they're in an entirely different plane in existence relative to Microsoft in this regard.
The most solid of their toolkits is far and away UIKit on iOS. It's got almost all of the best parts of AppKit with over a decade of thoughtful tweaks, polish, and QoL improvements. AppKit has become a bit more neglected since iOS stole the title of favorite child from macOS but is still quite solid. Both have an extensive set of highly capable stock widgets and with both, you can write just about anything imaginable pretty easily without importing a single third-party library. Neither locks you into a WYSIWYG editor or hand-editing XML and are pure-code-friendly, particularly since the addition of autolayout anchors.
SwiftUI is finally getting to the point where it's not so green and is becoming a more practical choice. Though it wasn't a headliner, this recent WWDC brought a number of long called-for improvements.
By contrast, WinUI lacks such fundamental basics as a tableview/datagrid, meaning you're going to be rolling your own or importing third-party widgets much more frequently. While you're not as locked into XML layouts and resources as one would be with Android Framework with it, it's not as friendly to pure code. It's also decidedly mobile-esque relative to AppKit (likely owing to its UWP heritage) which might be a problem if the goal is to build a true desktop-class app.
> uses native Win32 components and offers no styling options
It's a feature.
Custom styling should be considered a hostile pattern in most cases, except in highly specialized software with workflows dependent on prior user experience, such as DAWs.
I think loads of energy is wasted in development because someone wants custom stuff like buttons or input boxes without real reason where off the shelf GUI would work and would be much cheaper.
> Custom styling should be considered a hostile pattern in most cases
Why? Almost every website has custom styling and yet it doesn't seem to inhibit users from using them.
Good UI/UX patterns seems to be universal. As consistency is part of good UI/UX there are things that should be consistent with the underlying platform. But consistency with the platform is not equally important for all things. For some things, like window management, it's much more crucial, that it is for other things, like roundness of buttons.
> except in highly specialized software with workflows dependent on prior user experience, such as DAWs
It's not just about prior user experience. If a custom control enhances UX for a specialized task, it has a good reason to break some of the consistency. All specialized software (DAWs, graphics applications, IDEs etc.) have such features. Limiting themselves to just native components would lead to a suboptimal user experience.
How would you know inconsistency among websites isn't inhibiting users from using them? There's not a Web A and Web B to do A/B testing on.
Roundness of buttons? Buttons shouldn't be round in the first place. Back in the day, they were these rectangular things with a shadow and a highlight. You could instantly things you can and cannot click on. Now, it's anyone's guess. Do people click on the wrong stuff? Do people fail to discover functionality because it's hidden in plain sight? Of course they do!
Is there a place for custom components, yes, but not to the extent that every website out there is styling their buttons, and that even Windows itself is hiding scroll bars.
Modern UIs are not perfect by any means, but from what I remember, those old UIs were not great either... even worse in terms of UX on average.
While consistency is important, placing it above all else, leads to suboptimal UX and bland UIs. How many times did you hear people raving about how great is the UI of an app build with a generic form builder?
> It would require me to write a custom paint function for every single control, which would take so much time I could raise a family in the meantime
This is a weird comment that shows the philosophy of old school win32 has not clicked for them. The key element in win32 is the wndproc. Most controls ask their parent what color they should be via a window message.
If you find this inconvenient, wrapping that in a small library to remove boiler plate is not a big deal.
> Most controls ask their parent what color they should be via a window message.
There are a LARGE number of areas where this is not provided, such as the text color of a disabled control or the checkbox area of a checkbox control. Even for the cases where such customization points were provided, many of them were broken when theming was added in Windows XP and in comctl32.dll version 6 in Vista, which ignores some of them in favor of theme colors or images. Menu colors, for example, are ignored when theming is enabled.
The result is that if you want something approaching a reasonable dark theme with Win32 stock controls, you will often need to resort to full owner-drawing of the controls. This is not a minor task.
Do you happen to have links to any good documentation/articles on this topic? I'm working on what amounts to a dark theme for Win32 controls and largely making it up as I go along, relying on tidbits and off-hand mentions from defunct blogs.
I have a reasonably complete implementation of dark mode in my open source application, Explorer++. It uses the standard Win32 controls and applies a variety of strategies to get something that looks more-or-less cohesive when dark mode is enabled. ThemeManager.cpp[0] contains the bulk of the functionality. It could be useful as a reference for how you might create a dark version of a standard Win32 control.
Afraid not, had to piece together a lot of it myself. There are lots of examples available for various components of varying quality -- you'll find some code examples that don't work well with high DPI or all of the sub-modes of a control.
Some controls like buttons, list boxes, list views are reasonably well behaved, especially when theming is turned off. Combo boxes and toolbars are more temperamental. Check boxes, scroll bars, menus, and message boxes require a lot of custom painting work.
Writing GUI apps is painful everywhere, and has been for years.
I remember the half-baked transition from Windows Forms to WPF, which was then taken-over by the Windows Phone initiative, which was also extremely painful and half-baked.
There's a reason electron is so popular, despite all the complaints about it as a platform. Don't blame the electron devs, blame Microsoft for completely failing to support their own platform. That lack of long-term support and consistency extends to a ton of areas in the Windows world, not just GUI development.
The lack of windows support for windows GUI's on windows is mind blowing. I remember absolutely whipping up Visual Basic line of business apps using the form designer in Visual Studio and data bound controls etc. If you wanted more there was MFC (with MTL developed by some insiders I guess at microsoft)
The absolute insanity of going to WPF (wasn't data binding via reflection -> these apps got horribly sluggish!) then to UWP (monster controls for touch I guess?) is honestly mind blowing. The emphasis on Universal Windows Platform as "the future" of app development is absurd. Every time the design language behind this infects another settings app in windows we LOSE functionality! Can you even have more than one settings window open anymore with the new and improved UWP?
Then there is WinUI? Then there is MAUI? THen there is blazor on the desktop?
Has Microsoft confused you yet? They've confused me. Each of these introduced as the best thing since sliced bread, and back with tooling with broken forms designers and more.
The problem with all of these technologies is that they were invented by different divisions of Microsoft to do different things. That, and Microsoft chasing the Next Big Thing.
What we consider to be "Win32 apps" are built with a framework in USER.dll, which is half reimplementation of the classic MacOS Toolbox API and half a pure-C object oriented class system. It's been here since the beginning, and is the lowest common denominator for getting anything on screen. Every other toolkit eventually opens a USER window, attaches the appropriate window class and wndprocs to it, and then yields CPU control to an event loop that, among other things, contains a Windows USER message pump.
USER, being an object-oriented, pure-C[0] API, is infamously verbose to work with. The "200 line Hello World" example everyone passed around back in the 90s is specifically that verbose because of all the bookkeeping you have to do for USER's sake. It is possible to build USER apps that work well, but it puts a lot of onus on the programmer. Even things like high-DPI support[1] or resizable windows are a pain in the ass because they all have to be implemented manually.
Microsoft's original answer for "USER is too hard" was to adopt Visual Basic or MFC as you mentioned. AFAIK .NET WinForms was also a wrapper around USER. This is why Windows had a cohesive visual appearance all the way through to Windows 7, because everything was just developer-friendly wrappers around common controls. Even third-party widget toolkits could incorporate those controls as subwindows as needed[2].
The problem with USER is that it was built for multiple windows and applications that render (using the CPU!) to a shared surface representing the final visible image. Modern toolkits instead have multiple separate surfaces and draw on them as needed before presenting a final image to a compositor that then mixes other windows together to get a final image. Windows Vista onward has the compositor, but the UI toolkits also need to be surface-aware instead of chucking a bunch of subwindows at DWM at the last minute.
WPF is the first attempt at a modern UI toolkit. Relative to USER resources are replaced with XAML and window classes replaced with... well, actual language classes. Except it was developed by the DevTools division (aka DevDiv), and only ran on .NET with managed code. If you had a native application or just didn't want to pay the cost of having a CLR VM, tough.
Then the iPhone launched. And the iPad launched. The thing is, good tablet UI needs GPU-acceleration up and down the stack, so Microsoft shat themselves, gave the Windows division (aka WinDiv) the keys to the castle, and they completely rewrote WPF in C++ with some fancy language projections. That became "Metro" in Windows 8, then "Modern UI" after a trademark dispute. Microsoft wanted Windows 8 to be a tablet OS, damn it, with full-screen only apps and no third-party app distribution.
And then most people just bought Surface tablets, opened the Desktop "app", and used the same USER apps they were used to, complaining about the Start Screen along the way. So Microsoft pivoted back to a normal desktop with Modern UI apps, which are now called UWP apps, and there's a whole bunch of new glue APIs to let you stick XAML subwindows inside of USER or just use UWP outside of AppX packages, which is what Windows 8 should have done, and now everything is just a mess. WinUI 3 is just an upgrade to the XAML library that UWP apps use, but it sounds like Yet Another Toolkit. MAUI is some kind of meta-toolkit like the old AWT on Java.
At some level, I can explain this, but it's not reasonable. There is no "native" UI toolkit or consistent look-and-feel on Windows anymore. I suspect this, more than anything else, is the reason why Windows killed Aero blur-behind everywhere, and why Electron apps are so damned popular now. HTML and CSS are almost as old as USER, but with consistent engineering support and developer experience.
USER is an enhanced clone of the MacOS API, so it's natural to see what Apple did when confronted with the same problems. MacOS didn't have an object system at all, you just threw a bunch of controls onto a list and the system rendered them. That (along with user mode applications) was actually one of the reasons why they bought NeXT. OSX's AppKit toolkit shipped with compatibility bridges for Toolbox apps, but it was still about as advanced as USER was when it came to GPU usage, given that it was built around the same era as Windows, just for beefier hardware.
So what did Apple do? They made AppKit speak layers. They wrote a whole new compositing system called CoreAnimation to do in-process compositing, with all the common controls knowing how to manage it and layer-unaware third-party controls just doing whatever made sense. And this itself was a trojan horse for UIKit: the compositing library had been written to support a touch tablet demo that was later rolled into the Purple project to produce the iPhone. Y'know, the thing that actually kicked Microsoft's ass so much they decided to fracture their development ecosystem into 40 different UI toolkits with confusing names. In comparison, on modern macOS the big split comes from SwiftUI and Catalyst, but those are both wrappers around AppKit controls rather than ground-up rewrites of UI toolkits nobody dares touch.
[0] Or possibly Pascal, given the MacOS heritage
[1] The correct way to do high-DPI is for the windowing toolkit to work exclusively in virtual coordinates. Physical device coordinates and their derivatives should be converted away from at the earliest possible convenience and converted back into as late as possible. At a minimum, no user-facing APIs should use physical coordinates.
USER does not do this, even though there's an option to make it do this, which has worked wonders on every non-DPI-aware app I've thrown at it.
[2] Or, alternatively, implement their own. My favorite story about this is Internet Explorer, which ships with it's own implementations of common controls specifically just so that HTML form elements don't have to hold an HWND each and can share the parent window.
AppX packages got a bad rep as well for a couple of reasons. Lots of new footguns when dealing with them or trying to remove them for imaging / mass deployment scenarios.
The first introduction to AppX was often a metric load of crap on the machine - see below for a sample of the type of AppX stuff that was the first introduction to AppX for some folks which were often low effort marketing type stuff.
> Writing GUI apps is painful everywhere, and has been for years.
Disagree. GUI development on Apple platforms using either UIKit or Appkit is something I've always found expressive, simple, and fun. SwiftUI is a different beast, but to say it's painful everywhere is not accurate.
Windows Forms (C#) is basically a continuation of Visual Basic, it's not very painful at all. The only painful bits are when you need to lock a bitmap and deal with raw pointers, and you need to use the "unsafe" keyword.
To me, Windows Forms is where MS should have stayed. I don't want XAML to compile to C# code, and I don't want to be forced into using their MVVM system. I just want to be able to put boxes on the screen and fill them with text, then handle user interactions with callbacks. Basically, vanilla javascript but in C#
Flutter is actually quite nice and works well on desktop too. If Google continues to develop it I could see it becoming the first choice for a lot of developers.
Oddly AppKit seems to be one of the most stable desktop frameworks I have worked with. They've made breaking changes, sure, but they haven't been rewriting, and rewriting, and rewriting the same stuff for the last decade and a half.
The situation on Windows these days feels like... cognitive dissonance. If given a Windows app assignment today, I'd pick WinForms if less complicated, WPF if a larger project.
For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more.
If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows.
If you compile your C++ DLL with static C runtime, your C++ DLL won’t have any dependencies apart from OS components like kernel32.dll.
If you insist on having a single EXE you’ll need to bundle it and extract, but the additional code for the P/Invoke to work is like 4 lines of that code, call LoadLibraryW from kernel32.dll early on startup, before using any stuff with [DllImport] from that DLL.
I do not recommend C++ CLI. Write normal C++ which compiles into native code without any weird metadata. You can use C APIs, or COM interop with ATL, or check this library of mine https://github.com/Const-me/ComLightInterop/
If you start with this approach (as opposed to refactoring a C++ app you already have) you’ll find out that you need substantially less C++ than you expected. Essentially, C++ is only required for 2 things: CPU-bound number crunching, and code which consumes large C or C++ libraries (Windows SDK is huge and pieces like D3D or MediaFoundation require C++). It’s much easier to do everything else in C#, as the language and especially the standard library are just better.
I looked at various ways for interop between C# and C++ over the years, and overall found C++/CLI to be the best overall for our particular application types: it's a separate layer bewteen a C++ backend (which is also used in other non-gui applications), with a windows-only WPF desktop application on top. Mainly because the C++/CLI code itself is simple, readable and fairly effortless to write and maintain. A bit repetitive at times though, but that's going to be the case for any such layer AFAIK. Integration on the C# is seamless, with code completion etc, and C# interfaces can be implemented in C++/CLI directly for instance. The initial setup takes some work but with conversion between common types implemented (ability to e.g. IEnumerable<ManagedT> <-> std::vector<NativeT> or std::iterator<NativeT> etc) it's all pleasant and good.
Gotta say this looks neat, but it's exactly the type of code I'd rather not write: UUIDs, bunch of macros, unclear mapping between return types (HRESULT vs bool), having to declare same interfaces both in C++ and C#, ...
The language is only supported in a single compiler, and is specific to Windows.
The language is based on both C++ and .NET runtimes, and when I used it (admittedly, it was many years ago) I didn’t like the usability consequences. These two runtimes interact in a weird way. It’s hard to compose data structures which contain both managed and unmanaged pieces, see that question https://stackoverflow.com/q/10523268/126995 You can’t include Windows SDK headers in CLI code, not gonna compile: https://stackoverflow.com/q/26502283/126995 Same applies to most third-party C and C++ libraries.
So with CLI you have 3 languages instead of just two: C#, C++/CLI, and classic C++.
> it's exactly the type of code I'd rather not write
I have used that library in multiple projects in the last 5 years, for Windows and Linux platforms including ARM Linux, both open source and commercial. It worked great for my use cases.
As you see it has very few macros, no bool returning methods, very clean API between managed and unmanaged parts, and most importantly very readable idiomatic codes on both sides of the interop.
I’d like to add that if you make mistakes when writing these C++ and C# projection of a COM interface you’ll find very soon because it’s likely to crash on first use due to /GS compiler switch. Also trivial to debug and fix because VS supports mixed-mode debugging.
I’ve learned WPF long ago, and I no longer remember how specifically I did that. Still, that introduction seems pretty good at the first sight: https://wpf-tutorial.com/
Learning is easy, it’s very user friendly and IDE support is great. Mastering the framework for complicated GUI is harder. Here’s a few tips.
Treat XAML the same way as any other source code. Keep it human readable: write comments (the syntax is the same as in XML i.e. <!-- A comment --> ), and use proper indentation (I often use tab size = 2 for XAML files). When a particular window or control grows too huge, consider moving large pieces into separate XAML files with a user control or maybe a resource dictionary.
MVVM design pattern is great, use it whenever possible. Don’t forget to implement INotifyPropertyChanged and/or use ObservableCollection<T> for dynamic things. Having said that, I tend to avoid opinionated MVVM frameworks like Caliburn.Micro, IMO these things sacrifice simplicity for testability.
Sometimes for complicated UX use cases like drag/drop or mouse painting handling these input events in code behind is way simpler than trying to stick with MVVM. Luckily these approaches compose rather well; it’s possible to use MVVM for most of the UX and code behind logic only in the few places where it simplifies things.
Similarly, for diagrams or similar GUI you can directly create and manipulate these UI elements with C#, placing then on a canvas. Technically possible to do in MVVM-y way e.g. an ItemControl with a Canvas in the ItemsPanel, just much harder to do especially the layout on resize. BTW, you can define styles for these elements in XAML markup, no need to set up every possible font/brush in C#.
Couple advanced features I often use are IValueConverter interface to translate values or types between views and view models, and DataTemplateSelector to programmatically switch between multiple data templates.
I tend to avoid DataTrigger in XAML, I prefer exposing additional public properties from my view models.
WPF seems to be one of the preferred native UI platforms:
"Microsoft will refresh WPF with new Windows 11 theming and hyphen-based ligatures support for Microsoft .NET 9 and will continue to invest in WPF as one of the two preferred native user interface platforms on Windows."
The other preferred native UI platform seems to be WinUI 3: "WinUI 3 joins Windows Presentation Foundation (WPF) as the two recommended native UI platforms for developers."
Nope, the GUI story is so bad, that at BUILD 2024, WPF was made again an official Windows GUI framework for .NET devs, see BUILD 2024 sessions regarding Windows programming.
Haha.. That is too funny - I haven't been following this closely anymore. It's honestly wild. Does WPF still do data binding by reflection? I can usually "feel" a WPF app if I'm doing a lot of data work.
I remember when WinForms (which I thought was fine!) was killed. Why they just didn't continue to build on that I don't know (yes, I've heard the explanations, the importance of things like having XML (barf) in the framework).
How can you not be absolutely kicking butt on your own platform with a great story especially because they absolutely HAD a great story both at entry level LOB and advanced LOB.
WinForms is still actively developed (although it wasn't always).
I prefer XML to manually placing controls in a window and clicking around a designer GUI at all times. XML is trivially editable by hand, WinForms auto-generated C# isn't.
Supposedly is being worked on for making it more Native AOT friendly.
How we got into this mess? WinDev and DevDiv politcs.
After the Longhorn debacle, its technologies landed on DevDiv, like WCF and WPF.
Sinofsky and friends never were that keen in having .NET coming into their turf, it is no surprise that Hilo sample for Windows 7, then praises COM and C++ for Windows applications[0][1].
Then coming in this path, WinRT came to be, with roots as how .NET was being designed, before Microsoft decided to pivot it as another Java like technology[2].
A bunch of folks in WinDev, weren't happy with C++/CX, so they united to replace it with C++/WinRT, because extensions, when clang and GCC are full of extensions, promised to give back a C++/CX like developer experience in 2017[3], never delivered, went to have fun with Rust/WinRT.
Now C++/WinRT is in maintenance mode[4], and Rust/WinRT never took off, and is now Rust/windows-rs[5].
As paying customer, impacted by those childish attitudes, I would have had the whole team fired.
Finally, check the amount of bugs and complaints on their respective repos,
Mainly because along the way, as if those changes weren't enough, they also decided to reboot their initial approach with Project Reunion, WinAppSDK took another route, and here we are.
This is only a short overview of how WinRT went down since Windows 8, thus only those that never advocated for it, can honestly suggest WinUI, as they lack the background of how chaotic it all is.
This at least explains what from the outside looks like total insanity.
What's been confusing is they've been chasing all sorts of things (phones / tablets / web development) so clearly had money to burn, but couldn't deliver a basic solution for their own platform.
Clean simple line of business apps (ie, datagrid / listviews needs to work etc with bigger excel type datasets) + maybe RemoteApps or some other remoting option for SAAS type deployment would have been a nice option to have for plenty of folks.
For a lot of use cases the modern solutions are both worse to develop for AND are slower / buggier - so you get little for the effort
UWP was designed primarily for Windows phones, usability on desktops suffers. And it requires windows store, you can’t just ship an installer .exe
WinUI seems to be copy-pasted from UWP, same usability issues on desktops. Unlike UWP, it’s a mess in terms of software quality. Also the runtime is huge, I think the size in MB even exceeds Electron.
About MAUI, it seems Microsoft decided to make an abstraction over native controls. It’s been tried for decades and it always results in the same suboptimal result because these GUI frameworks implement the least common denominator of available UX. In addition to that, on Windows that thing uses WinUI3 backend, see the previous paragraph.
I don’t know anything about Blazor, but it seems that thing is for web apps?
MAUI is basically Xamarin.Forms, rebranded and rewritten, thus forcing the whole Xamarin community to rewrite their stuff, or go elsewhere.
Miguel de Icaza is pretty sour on this, and quite likely one of the reasons he is now fully into Apple ecosystem and Swift.
Blazor started with being only a WebAssembly based framework, then they decided to put everthing on ASP.NET under Blazor umbrella, and are now pushing Blazor into everything that has a Webview, including the stupid idea of Hybrid Blazor in MAUI, basically Electron in .NET.
Blazor is interesting. They are biting off an absolutely metric done of stuff. I will say their development style -> social media etc seems good which might help drive some buyin. They have public roadmaps. The outcomes still pretty rough ("Could not reconnect to the server") when falling off the happy path. So it still had a bit of that "in theory" development style that in terms of use annoys developers.
runFullTrust apps are still subject to file system and registry redirection as well as various capability checks. Running fully unencumbered requires restricted capabilities that only Microsoft can approve.
> This element requires the unvirtualizedResources restricted capability.
And if you click through the restricted capability link:
> If your app declares any restricted capabilities, then you must provide info during the app submission process in order to be approved to publish your app to the Microsoft Store.
The complaint is that writing GUI apps is painful not that it's impossible. In particular, when compared to other platforms, windows has had 30 years, several frameworks, market dominance, and they all still end up getting a D- for one reason or another.
Long compile times are annoying and affect productivity. Some people are really sensitive to this type of disruption and it gets very difficult to stay in flow when the only thing you can do is sit and stare at a progress bar. This is particularly offensive to C# developers.
Take your elitist attitude and your gigantic C++ monstrosity elsewhere. Tell me you haven't used a modern JIT language without telling me you're a scrub. Jesus.
Ah, yes, I must be a C++ advocate who has never used a “modern JIT language.” I’ve actually been using them since before the term “JIT” was in common use, just like I used C++ before it had templates or exceptions.
Incremental compile time on the order of a minute should not a big deal in a project. How would someone who can’t handle that have fared in our industry 30 years ago? Yes, faster compiles are nice, but they aren’t what will ultimately limit you unless you have an untreated medical condition.
Like the author I too did an evaluation of various UI frameworks, though I ended up settling on WTL (Win32 with some ATL). I might switch away from it and make my own Win32 wrapper in time but for now it works well enough and writing custom controls that feel like standard controls is relatively easy. If you handle the drawing correctly it is also one of the fastest and snappiest systems around.
I had the exact same issues with WinUI3, where each time I compiled and wanted to run the application I had to install it into Windows, with its own start menu entry and registry entries and all that stuff. Really inconvenient and not worth it unless you like and desire that "new app" look of the Settings etc.
Qt wasn't too bad but you still had to do a similar install step within CMake to make the necessary Qt DLLs available to your application to run it. It's also not the fastest system around for UI.
Why do you think Qt isn't fast? Qt apps can be VERY fast. My block editor[1], written in Qt C++ and QML is 4x faster than Bike - a native macOS app - that is already very efficient and performant.
I tried to write a windows App recently (maybe to put in the windows store). I gave up when ...
- Tried to wade through the mess of different frameworks. Some are abandoned, they all have different feature sets etc...
- I found that I could not have anything other than FullTrust (all permissions) if my app wanted to use the/live in the system tray.
- You can't set the size of the window to match the content. You can set a size, sort of, but the min is 500x500 AND it will remember what the user's last size was so if they e.g. maximize it will be the next time its opened regardless of the program settings. In order to do this simple thing I would have to write it as a WPF app with a installer (which as of 2023 can go on the Windows Store)
Dear ImGui is nice but beyond basic styling, it’s not exactly quick and easy to style. It also lacks any kind of accessibility features, which is fine when you’re making tools for games or similar (ie highly visual tools), but if you’re making anything meant for a wider audience, you really should use something with solid accessibility support so stuff like screen readers work.
> The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code).
I don’t understand how that makes WPF a non-viable solution. The author seems to have pretty strong feeling that it should absolutely be native code, but it’s not clear why
Yeah, I've done custom skinned apps in WPF that were deployed via zip file. Unzip and run the exe. Worked fine and even did p/invoke. Either they are ignorant about MS windows development or just a fanciful idea about how it should work.
Ooh I remember having a 'Windows API fundamentals' elective at college. I wrote an app with a couple buttons, menu and scrollable text area, but not much in terms of functionality, in pure C, that was all around well-behaved. It was more than a thousand lines.
> It would require me to write a custom paint function for every single control, which would take so much time I could raise a family in the meantime.
Implementing a custom paint routine is how you do theming in many UI toolkits. I get the impression the author is looking for a toolkit with declarative theming, like CSS.
Problem: It is extremely hard to stylize native Win32 controls.
That's not a problem, it's a feature. I am absolutely bloody sick of apps that go out of their way to reinvent the standard UI controls in perplexing ways and behave unexpectedly. Following the system UI preferences is what you should do, and it irritates your users if you don't.
There is a “hidden” dark mode for Win32 controls used by Windows File Explorer that you can activate, but it covers only some of the controls and still doesn’t look good.
Don't do that. If you use the regular Win32 controls then they will automatically get the styling the user has set.
I've been writing Win32 apps for close to 30 years now. It's sad to see the regression in UIs over the years.
1000 times this. I want software I'm running to look like the rest of the OS (and every other application) and respect my OS-level UI preferences.
In the case of Win32 using the OS primitive controls mean that your application gets tons of accessibility and preference features "for free" (albeit Microsoft has done a good job in later Windows releases of removing the functionality to set some of these preferences).
There is no value add in making your app UI look bespoke. All the labor you're putting into that work is labor that could be better spent on functionality, features, and optimization. When I see an overly "precious" UI on Windows (owner-drawn controls, animations, fades, etc) I immediately question the ability of the developer to prioritize.
Most users are unaware that there are UI standards, and have no basis for comparison. They use Google to help them figure out how to use apps, and take hand-written notes on how to find the things that they need. Once they figure out the functions in an UI that they need, they just pray that it doesn't change. The average user experience is horrific.
Devs that learned web frontend dev are not familiar with OS GUI guidelines. When I tell them Apple used to publish GUI guidelines for Mac application developers they stare at me in disbelief.
As a mobile dev, it should be the same for mobile apps?
If you are on iOS, you could just use what Apple gives you with very little customizations. The app would feel right, dark mode, font sizes, screen traders, etc. accessibility would "just work" 98% of the time, the app would be fast.
On Android, things are a tad bit more complicated, but it still applies that the closer you are to the OS, the better things work out of the box.
But for some reason, companies, their designers, product owners, developers want to get creative, use their brand but eventually they always run out of time to implement things properly, so apps are slow, user's font scale settings are not respected, dark mode is a feature, and the app doesn't feel like part of the same phone / OS.
I strongly believe that the amount of ironing they have to do for that crossplatform toolkit takes more time than just going with a common core and different UI shells.
Never coded a GUI app but speaking of regressions:
As a heavy windows KB user, losing the ability to alt+letter all the things to /quickly/ navigate windows apps is incredibly frustrating.
I've read that Mac OS envy infiltrated the WinUI time and while some may prefer the aesthetics, on Windows 11 apps like mspaint I can no longer navigate anywhere near as quickly.
From milliseconds to multiple seconds.
I'm incensed at this change personally, and I feel totally confused by it from the perspective of MS. In the era of AI and automation, slower screen draw times will make a significant impact to performance and energy use. I hope someone like Mark Russinovich, Kevin Scott, or Satya Nadella will notice and change course.
It's funny that you mentioned apple because their system shortcuts are integrated as hell and they even let you map them in the OS -> App level, way better than anything MS has ever shipped.
Yep, among other things both Apple-unique and emacs-esque text navigation shortcuts are in every native textfield across all apps and anything that's a menu item in any app can have its shortcut key rebound in System Settings without any extra work on the part of third-party devs.
It's one of the reasons why longtime Mac users are disinclined towards non-native apps. Most don't bother to reproduce these behaviors, and so when you as a user go to reach for these features that you have muscle memory for and they're not there, it's like hitting a brick wall in the middle of your workflow and makes the app in question feel basic and unrefined.
Don't forget you can type any of those menu items in the help dialog and it will not only tell you where it is, and not only let you activate it, it will helpfully show you the deeply nested set of submenus required to activate it.
Oh and of course those shortcuts are activateable by other applications to simplify app integration.
I sorely miss that menu search feature from macOS, even though it was unity's HUD on ubuntu that got me used to it in the first place. It's a shame it didn't become a more common feature, especially for programs with hundreds of options in the menu bar.
Annoyingly enough you don't really all keyboard shortcuts out of the box even if you build natively. If you create a Button(role: .destructive).keyboardShortcut(.defaultAction) in a SwiftUI dialog, you don't get Cmd+D as the shortcut even though Finder (and I think other apps too) uses Cmd+D as the keyboard shortcut for destructive confirmation dialogs. Thankfully at least a Button without destructive role will get Enter as its keyboard shortcut in the same context.
Yeah for now I keep most of my usage of SwiftUI restricted to non-Mac platforms. On macOS it’s fine for smaller bits like collectionview cells but has a number of rough edges for more major use cases.
At least you can hex-edit or resource-edit the Alt+Letter back into a standard windows button or menu that's missing an accelerator key. Just add the missing &.
> Those were only a few options that I considered. After a very long time trying out all sorts of different libraries and at one point even writing my own MFC styles, I figured out that for simple apps there is simply nothing better suited than Dear ImGui.
They decided to go with the option that deviates the most from the standard Windows UI, where there are no native controls at all, and it's a nightmare for accessibility (see https://github.com/ocornut/imgui/issues/4122). I use it for prototyping privately, but I'd never make anything I want to release into the world with it.
Life was good with Windows 2000, GTK2 and MacOS9, styling was clear and had purpose. GTK and MacOS even had extensive Human Interface Guide documentation.
As a non-Windows user, I'm confused, maybe you can clarify:
> If you use the regular Win32 controls then they will automatically get the styling the user has set.
Does that mean they'll get dark mode if the system is in dark mode?
In which case I don't understand what the author is complaining about. Sounds like dark mode would be working as intended.
They want "easy styling" but I took that to mean things like icons, some colors, etc. Not totally replacing what buttons look like. I agree -- being consistent with the OS is a good thing.
I don't think this actually reflects the new light/dark mode people are referring to here. It will most likely always be the default theme - light.
Also changing those old themes has a good chance to "break" any (poorly made) apps doing their own themes. You could change some colors in the palette and parts of the UI could end up being difficult or impossible to read. Happens if the app uses a combination of palette controlled colors and custom colors.
Correct. For Win32 apps, the only official support for dark mode is some WinRT APIs to tell if it’s enabled, so you can “adjust your application's painting and rendering code to use a Dark mode color set”
> Also changing those old themes has a good chance to "break" any (poorly made) apps doing their own themes.
They already do this. COLOR_3DFACE has gotten brighter with each successive version of Windows and in Windows 11 is #F0F0F0. I've had to fix UIs that became unreadable as a result.
No, they won't get dark mode and this is the biggest problem for Win32 UIs now. If Microsoft would make dark mode available for classic Win32 apps, it would meet all requirements of the original poster.
The problem with this hands off approach is that Microsoft has not updated its base controls and does not provide some capabilities out of the box. It instead only offers modern controls via its Win UI 3 framework, which is squarely designed for C#.
I wonder if this requirement has been imposed from above.
When the web was taking off I received designs from the UI architect in the form of VB6 applications. Windows was the dominant platform at the time. Never mind it made no sense in the context of more fluid HTML layouts. This was before CSS.
Since then the web has probably trained the holders of the reins that they can violate user interface norms everywhere.
I don't know what the situation is right now, but for the longest time ever standard win32 controls where even less useful and more anemic than even the standard web controls. There was always a disparity between what the OS gave you and what the actual good controls MS Office team would think of (until ribbon, but the original ribbon actually did have a lot of thought put into it).
This. But flares are still waiting to come back in this case. To get my foot in the door writing windows GUI programs I often have to obfuscate the fact I am using Delphi (don't ask, don't tell) or work with clients without big IT departments.
Disclaimer - No clients were ever injured during this experiment.
So much time spent on creating many different web frameworks to try and replicate the snapiness of native applications when the solution was to make native applications use web-tech so that both are equally slow. Mission accomplished! Genius!.
When people ask "why isn't there an awesome native widget set for my favorite language?" I have often said that GUIs are way, way, way harder than you think. It's easy to create a toolkit for your exact use case, but to create a toolkit that fits everyone's use cases to some degree is vastly, vastly larger than merely creating a programming language and a reasonable standard library. Vastly.
This is a great example of why. A small set of reasonable requirements and already almost all the options on what is probably the best-endowed OS for toolkits are almost all disqualified, and what did fit was an odd solution that won't work for a lot of other use cases. It isn't that these are unreasonable requests per se, it is that this is how this space works. Everybody has weird requirements of some sort, pretty much all the time, and getting even reasonable coverage is a huge, huge project.
Take a look at Win32 + Xaml Island.
You will find that most problems in WinUI 3 gone.
Because Xaml Island is a "system component", you don't need to install or bundle anything. And unpackaged .exe is supported.
There's one problem, if you want to use Xaml Designer in Visual Studio: Because .xaml files are compiled and packaged into a "resources.pri" file. You have to ship this file with your .exe program.
This can be solved by hooking system dll, see my project: https://github.com/ysc3839/SingleExeXamlIsland
It strikes me that having the C++ requirement is part of what makes this difficult. I'd like to have seen some reasoning why not to just use C#. Seems like it could have made some things easier, especially given the author's praise of XAML and acceptance of Visual Studio.
I'm not saying C# is better than C++, but just that choosing one over the other does have an impact.
> It strikes me that having the C++ requirement is part of what makes this difficult.
It doesn't.
In fact, it makes the problem even easier to solve due to the options that are already on the table. Virtually all .NET-based frameworks support C++ besides C#, specially WinUI3.
I work on several enterprise apps that are .NET but the GUI is a webcontainer with a web app. Unless there is something particularly high performance happening in the GUI, this works really well for several reasons:
1. We can update the gui without the user installing an update.
2. Lots of great web ui libraries, designers, and developers to make it look great.
Unlike Windows, Apple and Android have managed to publish modern UI libraries for their own platforms - but in both cases, this involved migrating the whole platform to a new programming language (Swift and Kotlin, respectively). If I remember right, C# also has a few features which were only added to make Windows Forms and WPF more ergonomic.
I'm starting to suspect that general-purpose languages just aren't flexible enough to keep up with changing fashions in UI development. Whenever somebody comes up with a new UI paradigm, you're not going to be able to take full advantage of it until somebody designs a new programming language with that paradigm in mind.
If so, this might explain why the Windows team keeps pushing new desktop UI libraries, only to abandon them within a few years - they just don't have the willingness or resources to migrate away from C# and C++, and so the quality of their UI libraries is stuck in 2006.
The issue is the React paradigm, which is a bit questionable to begin with. It's a sort of fake OOP in a trenchcoat pretending to be something else, whilst abusing the language in ways that requires compiler plugins. My experiences with Compose and SwiftUI have been ... not that great. I kinda wish people would just have kept investing in their OOP toolkits.
You're right that reactive UI is a poor fit for most languages (especially JavaScript!), but I think the problem is more general than that.
Good UI architecture needs some convenient and efficient way to propagate state changes between different parts of the UI framework [0]. This requirement sits in an awkward place, halfway between imperative programming and functional programming. It just isn't in the day-to-day vocabulary of any mainstream language, not even modern imperative languages which have a bit of functional programming mixed in.
I don't think OOP is any better at fulfilling this requirement. Being able to offload half of your program into a visual editor is nice, but it's cold comfort if the other half of your program ends up being a tangled mess of callbacks and data binding.
Yes you're absolutely right that these language dialects keep emerging because regular languages don't have quite the right features for reactive computations. Still, OOP was originally designed for GUIs and is a great fit for that, it's easier to build functional stuff on top than the other way around (apparently, judging from experience of having used both).
The closest I found to what I mean is that JavaFX has a whole observables framework, and there's ReactFX that builds a lot of stuff on top of it. With a small change that I prototyped in the past you can do what React Compiler is trying to do, where you run code and record what properties are read then register dependencies and re-run on change. It's quite a natural fit.
We already have a solution for most UI presented in this paper [1]. Functional programming let you represent the solution in a much nicer way after you've hidden the oop/imperative machinery away. But it's a complete package where the declarative part is only the shell. The UI part of any application should be considered as an external module, (like the data access layer) and the code architecture should reflect this. In an extreme way, if you can't create a telnet interface to you GUI software, that means your interface is already too coupled to the rest of the code.
There are solutions if you're not hell-bent on using C++, be it .Net, Lazarus (FreePascal) or Delphi. We're using Delphi at work and for the most part it's super simple and easy.
Delphi comes with so many db drivers, a data layer that will let you do crud, and an app store that using it feels like cheating. Especially with devexpress controls.
Indeed, QML and C++ together are the best mix out there for GUI development. I've written my block editor completely using Qt C++ & QML: https://www.get-plume.com/ and it was a breeze.
lazarus is great, but the GUI library it comes with has the same issues that the author is concerned about... try changing the theme colors to a dark theme... you end up with something looking like crap with all the other controls using standard colors.
Writing GUI apps for anything is painful, if we’re being honest. To this day I haven‘t seen a single good GUI framework for any of the platforms that I‘ve tried. Flutter feels nice though
UIKit has a few frustrating details, but overall it stands tall above the competition.
For a long time the main downside was that you had to deal with Objective C, which is a turnoff for some people.
Swift solved all this, and writing UIKit in Swift is mostly a joy. Sadly now SwiftUI is the new shiny thing, and it’s a major downgrade in most dimensions save for a few.
A cross platform framework that reuses UIKit conventions and supports all modern languages (C++/Rust/Go/Python/Nim) would be the dream.
This looks quite promising!
I love LUA simplicity and I've always wondered if I could built commercial-grade desktop apps with it. So far I only considered something like LOVE, but LuaRT could be a good alternative.
I just write GUI's in tkinter (python), build a single .exe with nuitka, and interface with generalized application functionality either as a .dll or python module ..
tkinter may not be the sexiest way to do things, but its definitely productive in terms of the code-compile-distribute methodology, and it is very easy to wire up to a generalized 'daemon'-style abstraction, where the app logic is implemented as a daemon, sent application commands over a well-greased socket.
With this architecture, I no longer care that its Windows underneath - this is just another platform target - and can easily use either MacOS or Linux as the development environment, needing only to test on Windows, ultimately.
Anything beyond the sphere offered by tkinter is just less appealing. If I have to start treating a platform target in any kind of 'special' way, I just lose interest in that target, as a whole - however, from a UI perspective, Windows tkinter support hasn't been that bad, and generally keeps up fine.
(Disclaimer: if I really need performance, I also use the JUCE framework for my needs - even though its an audio-centric framework, you can build GUI apps with it just as well, and its also a cross-platform way to do things in pure C++ ..)
Oh god, seeing TkInter applications, and inevitably, having to fix them particularly on macOS just fills me with rage. Whoever reads this - do not use TkInter.
Whats wrong with tkinter? You're negative experience can't possibly be the standard by which 15+ years of productive use of it is to be discarded .. perhaps you haven't learned how to make beautiful UI's with it, but some of us have ..
You can easily go from Figma -> tkInter code -> app, too.
I have ideas about writing a GUI framework [1], but why in the world would I spend the time to make it up to the author's standards unless someone was paying me?
GUIs are a lot of work. People should be more willing to pay for work like that. Wanting everything free is one reason Big Tech has so much control.
The amount of bloat everywhere today is simply disgusting; just because my group server has 1 TB of RAM isn't a justification for letting a "hello world" app grow to more than 50 kB, GUI or not.
Yes, productivity is more important than squeezing out the last bit nowadays, but that the poster couldn't get his 40 MB limit satisfied shames the whole software industry. He should get a simple (i.e., half a dozen menus, dialogs, windows) GUI app done in 400 kB (it was possible in the past).
Apps developed for the modern (open-source) version of .NET may be compiled to a native code (NativeAOT). Some time ago, I tried AOT on a simple WinForms project and it worked. Unfortunately, functions using COM APIs are not yet supported (as they rely on reflection). There is an ongoing effort to fix this problem: https://github.com/dotnet/winforms/issues/4649
One thing I learned about the software industry is that a lot of the tools we use are objectively horrible, but it doesn't matter because somehow big tech manages to shove it in our faces anyway.
Also, the inverse that really good software tools often don't see the light of day is also true. It really doesn't matter if some tool is good or bad for adoption. What matters is; does it have the backing of big tech? It shows that tech media is completely monopolized.
The painful bit is C++. I did a fair bit of that going back to MFC. Knocking stuff out in C# with WPF and WinForms was quite nice in comparison. I haven’t found anything nicer.
C# with WPF or WinForms only seems nice in comparison to other relatively painful tools IMO.
The old RAD graphical tools and newer ones like Rebol (that are now dated) show just what is possible. Mathematica is also pretty powerful and doesn't require a ton of code.
I think there is a thing called Microsoft Office development kit or some other name that allows C# and other .Net programs to manipulate Office apps. Not sure if it's what the author meant, though.
Oh, I have used OLE (or some iteration thereof) to drive Excel from Python. That was a long time ago, but it sounds similar. I wasn't really doing GUI, though - I was using code to build spreadsheets from data files.
I had something I wrote in the 90s I wasn't proud of that was a word macro that read Excel sheets for a list of instructions and used those to compose documents and print them. I feel sick thinking about it.
> The painful bit is C++. I did a fair bit of that going back to MFC.
I'm sorry but referring to MFC while referring C++ is a telltale sign you don't really have any meaningful experience in the field. Developing GUI apps for Windows is a breeze with frameworks like Qt. You only suffer if you're a masochist, but the rest of us prefer to pick things that make sense.
I have a lot of experience, in the real world, which is somewhat less ideal than "just use Qt - it's a breeze".
How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts?
Aye you fuck off and work somewhere else that's what you do. Which is why it's still written in win32 native, ATL, MFC, custom GDI+ wrappers.
They paid two companies to come in and rewrite it, first in Qt which was a complete failure. Then in Electron etc, which was also a failure.
> How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts?
You're complaining about your personal legacy "chunks of win32 native, ATL, MFC, custom GDI+ wrappers".
Not C++. Just your personal legacy projects you didn't managed to maintain or update.
C++ doesn't magically rewrite your technical debt. You need to do your work.
Open source GUI libraries are lacking behind the gate locked, closed ones like Adobe. Even Macromedia UI back in the days 20 years ago looks way more appealing and polished than the current open source offering. The only polished open source UI in my opinion is Blender but apparently they have their own rendering engine built from scratch just like Adobe.
One would think that after three decades of the windows metaphor and billions of man-hours writing such applications, writing GUI apps (for any platform) would be a much more pleasant experience?
One could imagine a framework that would absorb all this historical know-how and turn GUI app development into a zero marginal cost exercise (fast, functional, cheap and maybe even pleasant) but who would push for this and why?
Maybe its a case of somebody not learning a lesson when their economic interest depends on not learning it?The overview of existing frameworks (including browser/webview based) suggests there is a sort of stagnating stalemate that feels sub-par but probably works just fine for those who have any leverage over the status-quo.
There is a UI framework which is fast, functional, cheap, and (depending on your personality) pleasant: the web browser.
HTML and CSS are go-to strategies not just because the web is the target platform for probably most if not almost all user interfacing software these days, but because HTML and CSS are very forgiving. Native UI frameworks are written by software engineers who demand type safety and XAML-like features which convert declarative syntax into imperative/object-oriented C#. The truth is that the vast majority of people who work on user interfaces are not the kinds of software engineers who enjoy this; HTML's model of creating arbitrary blobs of flexible dom nodes (and then using javascript to handle user interactions) is a lot more pleasant than getting compilation error after compilation error in XAML and having to google how the hell you display a set of items in a ListBox, only to have to filter through 4 or 5 different slight variations in the proper types between WinUI 3, WPF, UWP, and Maui.
Native desktop software will never beat web browsers as long as you're forced into using the framework's model for structuring your data and code. 13 year olds learn HTML, CSS, and Javascript, that should be the target for usability with native UI frameworks
There is certainly a strong case for the web platform as an all-weather gui platform but on actual mobile and desktops of here and now it is not a no-brainer choice. Its document oriented nature fits some use cases better than others. Not to mention that with the near exclusive focus on (incompatible) javascript frameworks it is not exactly clear even what "html" means...
It seems to have become the no-brainer choice. Lots of mobile apps just load html views, and probably most desktop apps I see these days are just electron apps. You can reason about the best use case for HTML vs XAML vs Swift, but it seems that the speed of development time and the insane amount of community support out there has made the web the clear winner
And the quality of software has gone downhill. HTML and CSS can be RAD, but they rely on millions of line of code in the browser engine while having subpar models for gui layouts and custom widgets. And building a native app is not that necessarily complex, it's just different.
The market prioritizes speed of development and cost of labor over runtime efficiency. Thus, until native app frameworks become easy and fast to develop for, we will continue to see everything turn into a web app
>The issue is that with bundling the .dll, it would still mean it being extracted somewhere
Hmm, this got me thinking about stuffing native code into CLR image. If you would just include additional executable code sections into PE, would loader map them normally? Or presence of IMAGE_DIRECTORY_ENTRY_COMHEADER would stop it from mapping native code? If so, maybe you could remove that header and manually do pre-XP style initialization, by calling _CorExeMain from imported mscoree.dll. Though you would need to somehow trick it into locating COMHEADER that we removed.
As someone who spent most of the early 1990's writing Win32 apps, it doesn't seem like much has changed! MFC has always been a pain to use, especially coming from X and Motif.. even Athena widgets were better than MFC.
I've used QT in the past decade for MWL (Mac/Win/Lin) and it is a bit clunky compared to the graphical fluidity of Electron. We just need a solid effort to make Electron smaller. Granted, one can build smaller variants, but even 100 MB is far too large.
I'm a fan of a self hosted web service bound only to localhost, then you serve a HTML with all the bells and whistles from that web service. I think they used to call it OWIN.
I guess the major downside is that you might get a localhost cert warning if you don't install a self-signed cert and a root cert in the PC's cert store (which yes, yikes)
Nope, not at all. Winforms is still actively maintained and sports native advanced features like MVVM and async support. And winforms is not even the only option.
> Writing the GUI part of the program should not take more time than the actual functionality
I can't stand this mentality. The GUI is your functionality. The rest as far as the user is concerned may as well be pixies and fairy dust. Treating UI as an afterthought is why we've ended up with so much nightmarish crap these days.
What are the issues the author alludes to about AppX packages sucking? Looks like the new Fluent stuff wants you to use those. Curious to know what pain points exist there.
This was a big reason I switched to the mac many years ago. I was a win32 programmer professionally, but I was more productive on mac after a week or so of hobby fiddling around.
There is simply no contest. MacOS 10.0 was far superior as an environment to develop desktop apps when released, than Microsoft Windows is today with any toolkit you might want to choose.
I've had a good experience with JavaFX and I even managed to AOT compile two faily complex applications of mine. My advice would just be to stay away from FXML. Also use jlink to build a stripped down JRE for your application and package it with jpackage.
First of all, this is an immediate rendering library which is a very inefficient way of rendering the UI for any application that is not a videogame. You are rendering the UI 60 times a second, regardless of whether something changed or not. Most UI frameworks only update when something changes.
Secondly, there are things in GUI frameworks that most people don't think about, such as accessibility. Windows has a builtin accessibility API where apps can declare the objects being shown on the screen, so that screen readers can interact with the application. I'm pretty sure this guys framework doesn't have that.
The author would have been served extremely well by AvaloniaUI with NativeAOT target if they were willing to drop their assumptions regarding C# that are no longer true. (I wonder how well Uno Platform fares in comparison? It targets native controls first and foremost but is supposedly NativeAOT compatible too)
Not an expert, but could you use something like https://enigmaprotector.com/en/aboutvb.html to virtualize a file system to create a portable exe. Not sure if the size would exceed your specs.
While I have dabbled in a number of GUI libraries - many of them were a few years ago so covering my views on those would be disingenuous. I remember using Win32 or MFC.. and dabbled in Qt, etc.
In recent years, I have used WPF/Avalonia and while they are good - can lead to a lot of bloat following MVVM.
In the last year, I remember needing an application that shows a map. I tried to find support for openstreetmap and, while they exist, did not support what I needed to do. I tried Avalonia, and then GTK, etc. To be honest, I really liked GTK.. it just didn't have the tools I needed, sadly.
I have leaned to immediate mode UIs these days. I like I can create something with minimal code. Sadly, no openstreetmap support from what I can see.
In the end, I created a web interface. openstreetmap (leaflet) did everything I needed.
Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK.
It MUST be open spec. It MUST be free for all/any to implement. It MUST either be included or be in the primary vendor (MS, Apple, distro) software center.
A simple Hello World, click OK to exit the program application should be able to be cross-compiled for any platform, and the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does. It SHOULD be a small entirely dynamic program; possibly a few hundred kilobytes at most but even that seems too large. After all, it would mostly be the basic boilerplate of setting up memory, calling the system library loader, and linking in the shared libraries.
I hope they don’t. I like that the different platforms I use feel and look different. In fact, I wish there was more variety. I wish there were still Atari, and Amiga, and BeOS, Tandy, and all the other interesting platforms competing for users with different ideas of how computers should work.
I wonder how possible it is to design a cross-platform GUI framework that not only uses the native UI widgets of each underlying platform, but also respects each platform's human interface guidelines. I'd imagine this would be very hard work, especially the part about respecting each platform's HIG, but the increased power of AI tools could potentially make this task easier. Such a framework could potentially be an appealing alternative to Electron for making cross-platform applications, with the benefit of conformity to each platform's HIG.
There have been many frameworks that offered this and some still do. But it comes at the direct expense of design discipline, branding, and user experience optimization -- all of which have been elevetated to high concern over the 15 years or so.
Cross-platform "Native look and feel" currently works for some no-nonsense professional utitlies and hobby tools, but mostly makes software that's hard to sell, document, or support.
Most have just opted for common widget libraries instead, and frameworks have stepped up by providing rich libraries of such widgets and prioritizing features for customizing or complementing them even further.
I’ve been thinking more lately about a library which defines an interface for GUI elements, and then leaves implementing that up to you. Something like MVC (or some other design pattern) where the view part is an interface definition.
I think OpenStep actually had something like this in mind and had a Windows implementation too. It's apparently even used in Apple Windows apps like Safari, but of course it must not be complete enough to be able to fully replace native Windows API, and the incentive isn't there either.
In both OpenStep Enterprise and Yellow Box for Windows, while the UI elements still have some NeXT-isms, it's not terribly out of place, either.
However, this got scrapped sometime when Apple abandoned Rhapsody (which had PowerPC and x86 versions) in favor of Mac OS X (which was originally only available for PowerPC until the Intel switch in 2006, though Apple maintained an x86 version internally during the PowerPC years). During the transition from Rhapsody to Mac OS X, Yellow Box was renamed Cocoa.
The impetus here is that Adobe had initially promised a free, then low-cost license for Display PostScript --- when that was pulled, Apple had to come up with an alternative --- that and the fact that all the major app vendors announced that they weren't willing to do top--to-bottom re-writes using the NeXT frameworks (there was even a rumor that "Yellow Box" was named for the sake of Bill Gates' comment, "Develop for NeXTstep? I'll piss on it.")
So, Apple, led by Mike Paquette and many other talented folks from NeXT created Quartz (née Display PDF) and Carbon and instead of a consistent environment with a single API, we got an assemblage of technologies which had a Calculator app written in Java which took _forever_ to load, a Finder written in Carbon instead of Workplace.app, and icons cluttering the desktop and a Sidebar instead of a Shelf, and a bunch of Carbon apps.
> Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK.
I've been saying for a while now that the open source world would have benefited if more effort than what went into GNUStep had been focused on copying Cocoa to the point that it rather than GTK or Qt had been the toolkit of choice for the Linux Desktop. Especially when there was a major infusion of interest circa 2010 of folks adopting the MacBook Pro as the developer machine of choice.
I think it's still doable. And I mean down to looks, too, and not just API feel. Aqua from the same time period (Snow Leopard through Mountain Lion era) is the closest thing I can think of to timeless visual design.
It's true that if everyone just made Cocoa apps that looked like they were created with Mac OS in mind it would look out of place on Windows and elsewhere, but (a) it would still look rather good, and (b) it would not look any more out of place than anything else, including Electron and even lots of "native" apps, due to the proliferation of toolkits described in the article not to mention the Gnome identity crisis that has only just recently begun to get reigned in—mostly by following Mac OS cues and being more consistent than before. It's just a shame that it stops at the surface level and doesn't carry over into the actual APIs. Plus those cues are from the post-flattening of UI.
If anything is going to get copied by Linux as is... it'll be Win32 API so mono / C# stuff can bind directly to that, and Mac/OSX will be even more isolated.
For something to be portable everywhere it'll have to be an industry standard that the existing industry buys into.
This exists. It's called wxWidgets. It's an API shim over native components plus some convenience classes for abstracting out OS-specific functionality. It's LGPL with static linking exception, so no DLL hell.
The library exists, BUT it is NOT shipped natively and NOT (AFAIK) something which trying to run a random downloaded utility app will trigger the system library loader prompting for the 'common wxWidgets runtime, for free, codesigned by Microsoft' download and install from the store to run the app.
> the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does
If there's no DLL required then why does it matter if the DLL is automatically downloaded from the Microsoft store? DLLs are not useful for statically linked binaries.
they don't need to do this and likely don't care to. web ui exists. microsoft doesn't even care about native anymore. they are focusing on .net maui cross platform/web (with blazor) stuff and AI.
the days of snappy portable applications are over. unless you want to stick with win32. and nothing wrong with that. in win32, you have the tools to create any look and feel you want. the author just doesn't care put in the time to do that and wants something pre-built while conforming to his demands.
On the rare occasion I find myself needing to write a windows gui, I just use winforms. I don't have to muck about with XML nonsense and it just works.
Leave the OS to style controls how it does, for consistency. There is no reason to be inconsistent. This is not 1994 and you’re not writing a warez keygen
What was your problems when using Flutter for desktop?
For me, it's the lack of multi-window support. There's a community solution but it's a bit lacking because it spawns another engine while the upcoming official solution uses single engine.
I personally use it for my desktop apps (cross-platform) and building UI for it is a breeze. Though I forked someone's window styling plugin because it's missing some features I need. A native dev would've done better than me but if it works it works I guess.
If I had to satisfy the requirement in the post though, I'd use enigma protector with to make the app folder into a standalone exe and with compression enabled to make it smaller.
Shoutout to the Rust library `iced` which is cross-platform, amazing, and can do anything you need it to at blazing fast speed and low memory footprint: https://github.com/iced-rs/iced
I've been using EGUI to write GUI programs. Works nicely and runs on both Linux and Windows without notable differences. (I haven't tried Mac, but it presumably will work there as well without changes). Small binaries (a few Mb), and can integrate with maps, 3D rendering etc.
I don't do a lot of desktop apps but for simple GUI apps I've been using Python and Pywebview, with packaging left to Pyinstaller. The main reason is that I get to reuse the python/javascript/css libs that I know, and it's easily portable. I'm sure a native app uses less memory and cpu but frankly what I get with this combination is not that resource hungry. In fact, anytime something goes south it's my fault for using poor algos. Also, there are tons of great GUI libs and web components.
I was going to suggest embedding the native WebView ActiveX control (which I did in the past with great success) but it turns out the WebView has been updated and wants end users to download and install the Chromium-based runtime library nowadays.
Delphi is the superlative windows desktop development tool. It does support styling and just about anything else you would want. There is a free alternative in Lazarus but I don’t know if it supports styling
I've been a strong lover of Qt, but I've just undestood that one cannot statically link it. Tbh it's never been the case in my situation, usually writing in PySide bindings which will never link dll/so libraries, however in certain situations this would get really expensive, if static linking would be required.
I am writing this article while it’s 32°C inside my room.
It took a horrendous heat to make a programmer find the best GUI library, but it was worth it! 500KB for imgui? Seriously? I remember Inno Setup creator saying that we was compiling his 'boot' application (to reduce size, because it was glued as a prefix to a zip file) in Delphi 2...
I love GTK, but compiling it on non-native platforms is torture. If you're lucky enough to get a build environment working, compilation can take hours just to yield a horribly buggy and slow GUI.
I really wish GTK worked better cross-platform, but I mostly use it for Linux-only stuff. It's not humane to make Windows and Mac users suffer through it, unfortunately.
Tested Geany Editor on Windows the other day, it uses GTK, great editor but horribly slow on Windows, just scrolling a small file (less than 100 lines) was sluggish.
MSYS2. And copy over prebuilt dependencies. And while we say C++, I suggest always to use Meson as build tool. Which allows you to use WrapDB (built in dependency-manager) aside from available native libraries and own local sources.
The problem about Windows is, that Microsoft adds new APIs repeatingly and doesn’t care much about the previous ones. While on Linux we’ve Gtk1, Gtk2, Gtk3 and Gtk4.
And while people complain about deprecations and changes they actually mean „API changes require work to use the new major. But these people keep maintaining it. And provide upgrade paths to enhanced versions? I’m in!“.
HiDPI, Wayland, new Widgets, new renderers and a scene-graph.
PS: If you need to keep it small and simple and address professional (power) users I suggest a TUI with the venerable ncurses. Or notcurses.
Frankly Qt is the only sane option. Just give up on the "single static exe" requirement. Your users will have to unzip a zip. Hardly a big deal. Certainly not worth switching your entire stack to something vastly inferior for.
Depending on if he lives in a apartment some country/cities have laws against doing any work in the appartment that impacts the outside without permission from the house owner.
E.g. you can buy a heatpump but you can't drill the hole in the outer wall.
In germany and austria most if not all windows also either open fully to one side or basically bend inwards so you can't install the ac units you install directly into the windows[1].
Are portable AC units not available in Europe? They are inefficient but can sit inside next to the window and only require that you partially block off a window opening.
Power isn't cheap, and inefficient is an understatement. In the heatwave last week in Germany I managed to get ours to cool a tiny bedroom from 30 to maybe 26 degrees Celsius.
Doesn't help that in new construction outer walls are usually very well insulated, and inner walls and floors aren't (by design; 70% of total heating cost is evenly split too), so you're working against your neighbors too. We have some stupidly complex building standards often driven by industry lobbying (which also makes building expensive), but installing a mini split hasn't made it on the list.
They definitely exist, and are very cheap. I got one for 200, gave away to a friend when I moved out of an attic apartment. They have a window-attachment accessory that makes it easy to attach to those European windows.
The real reason most of us don't have AC is because it's hot for a very short period. Last year it definitely wasn't too hot for me to warrant having one. This year so far, it was, for a week: we had about 30°C (86°F) last week, but next week my mobile phone promises it's gonna be 20°C (68°F) maximum, which does not need AC. Maybe that will change, though.
I don't know what landlords are like in European countries, but some landlords in America forbid people from connecting any kind of AC exhaust port to a window.
It's funny that in this case the law now protects you.
Generally anything you do indoor that falls under normal usage(painting walls, hanging furniture with big screws,etc.) is ok without approval, at least in my country/city(austria) and the land lord can't deny any of this and is not even required to be notified.
As you would have an open window and a not so noise machine running this would be ok, but energy efficiency is quite bad and you lose the benefits of the thermal insulation of your building.
Yeah, the GP comment is classic HN. Wildly vague, with no supporting evidence. The planning rules in the US are fractally complex compared to "Europe".
Works just fine, I have 8000 BTU and it cools a living room very efficiently. I need it about one or two weeks per year in Finland. I can't imagine anybody working from home without one, even as north as Finland. Although we Finns are probably least used to heat so even 27 celsius is unbearable.
The only thing one needs is a window-sized cardboard with a round hole and blanket if your target room has no door. I just looked at prices and 10000BTU seemed to be ~350 euros.
I bought a portable split system for 2400 EUR. Works pretty well since I have shutters and a balcony, I put the external part outside the window, pull down the shutters and seal the lower part of the window around the pipe with some stuff. Doesn't use lots of power if I cool to 26C. Well, today we had 34C outside, so it had to work a lot.
Sure thing: https://www.amazon.de/-/en/gp/product/B07YZ5XT92/
Maybe it was a bit less, 2200 with shipping.
I do have a top floor apartment looking south, so I get a constant 30C+ in summer, without any cooling at night.
It can be hard to justify the cost of installing and maintaining any form of household cooling in colder areas of Europe. Additionally a lot of apartment buildings don't have them, and most landlords probably wouldn't appreciate a tenant installing one without permission. Evidently heatwaves are becoming common enough now that most people should probably keep a window AC unit ready in case of emergencies though.
As an European from Spain, in south European countries air conditioners are essential(Greece, Spain, South Italy, South Spain, inner Portugal). But in other countries or places it is not really necessary(north of Spain, France, UK, Germany).
Some days of Summer it is hot there, and they are not prepared for that like people of the South of Italy or Spain, and there is chaos.
It is like when it snows heavily in Madrid:
https://en.wikipedia.org/wiki/Storm_Filomena
In places like Austria or Switzerland it would be routine. They are prepared and it would be not a big deal, but in Madrid it stopped everything for two weeks.
He also says it's 32C, which is slightly less than 90F.
Interestingly, some people would describe that temperature as only "warm". I recently watched a video of a machinist working in his shop (southern US) saying that it was 94 and "a little warm".
Unfortunately, if you are insisting on a single exe file, then you have to be way more flexible on your requirements than the author is. There’s a reason that practically every Windows program has an installer. It’s stupid and a waste of time but also probably more of a waste of time to try to be the exception to this rule.
Frankly I don’t see why C# targeting an old (3.5?) .NET framework version wouldn’t work for the author. There seems to be a tendency to fixate on how things should be vs where we are now. C++ native GUI dev is not a mainstay like it used to be.
Real question: Is a single exe not possible when targeting .NET Framework 3.5? Or is the problem that the sum of their silly requirements makes it impossible?
It should be quite possible to target .NET 3.5 and hit all the other requirements, except native C++. They hinted at this and then started talking about C++/CLI. If there’s ever a tool of last resort, that is it.
"Problem: It is extremely hard to stylize native Win32 controls."
No. Don't style them. Let the users settings dictate how your app looks. This is the correct way.
I would like to show my appreciation to the author of this blog, although a lot of comments here show otherwise, as the restrictions the author has involved here are considered as "unrealistic" or "unreasonable".
Whenever an article is trying to compare several options, it is very important to know beforehand what the author is trying to achieve, and what the restrictions are. And in this blog, the author has clearly stated that the restrictions are to develop a GUI within 40MB and should be easy styling. No one should judge the author for the restrictions, as it may be from the author's specific needs, or directly come from the client's requirements. The clear restrictions are also very helpful for readers like me to understand the trade-offs the author has made, which is not something that I have to do myself, but I can definitely learn from the author's experience. If I am in a similar situation, or even with different restrictions and need to make a different trade-off, the author's experience can still be very helpful for me.
Just want to call out that it is not a fair ask for a blog post to exhaustively compare all the options, as it is very time-consuming for even a paying job. We learnt the specific restrictions that the author is facing to, and we learnt the author's experience with the options that the author has tried. That is already a lot of value that the author has provided to us, and I would like to thank the author for that.
The solution you end up with will be a compromise on your requirements. E.g. if you can compromise on the 40MB size requirement then Electron should be a good fit to cover all your other requirements.
Unfortunely it is built on top of WinUI 3, with all the warts it entails.
Mostly because since they killed C++/CX, there is no UI tooling story for doing XAML C++, without having to deal with IDL COM like mess in Visual Studio, only worse in WinRT case.
> Unfortunely it is built on top of WinUI 3, with all the warts it entails.
I'm not sure that's relevant. The whole point of React Native is that you do not touch the underlying framework. Instead of churning out XAML, you just write React and let the framework bother with how the GUI is implemented under the hood.
I swear to God if I ever downloaded a piece of open source software from GitHub, opened it, and saw the deformed Windows 8 Metro UI gawping back at me, I would do everything in my power to wipe the blighted individual responsible from the face of the fucking Earth
This is a good overview of some of the options, but the author’s specific requirements push it in a specific direction that eliminates a lot of options.
Specifically, the requirement for completely custom GUI styling without writing his own render functions means it’s really a task of selecting easy, customizable GUI libraries rather than generic GUI work.
The requirements to be self-contained executables and under a 40MB limit also rule out a lot of options. The author admits that Qt could have met these requirements but the open-source licensing part wasn’t compatible with his goals and he didn’t want to pay for a license.
If you relax the requirements to tolerate some dependencies, allow larger download sizes, or to simply use built-in Windows GUI controls the situation is very different.
For writing a lightweight, completely custom GUI with no external dependencies and permissive licensing I could have guessed ImGui would be the answer before I started reading.
If instead of insisting on custom UI styling the author just used the system UI, they could probably build a pretty straightforward Windows application. It’s the scourge of “brand identity” that has people thinking graphical applications are hard.
Same on the Mac: If you want to build a Mac application, your best bet will be AppKit or SwiftUI and using system controls. And when the OS updates your application will either update with it, or need only minor tweaks and a rebuild to look good.
This indeed. Custom UI widgets for Windows apps are really not necessary most of the time, and fitting in with the system theme is all you ought to aim for, most of the time.
There are exceptions, for very rich dense UI, for UIs that need to be cross-platform, but if you're writing a Windows app, it should look and feel like a Windows app.
> There are exceptions, for very rich dense UI, for UIs that need to be cross-platform
That’s not exceptional at all. That’s completely normal requirements that are probably in the majority.
Does Microsoft themselves build their apps this way?
Most applications would be fine with a button on Windows looking like a Windows button, a button on Mac looking like a Mac button, a button on Android looking like a Material Design button and a button on iPhone looking like a UIKit button.
You need consistency in the icons, layouts and concepts, but you don't need every widget to look exactly the same on every platform.
Right. I want your app to have consistency with the platform I’m using. Not between all platforms.
With the exception of games try to use the native GUI. It’s the best choice most of the time.
Depends on the app size also.
Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.
Is your app very large but not that large? (Slack/teams come to mind) I think you can go either way.
If you are smaller than that (hint: you are) then you should comply with the design language of the platform, even if that means somewhat large changes such as moving buttons from the left to the right. The likelihood that users are constantly using your app on a iphone and android is really low.
I disagree. I think the only apps where a custom UI make sense are games and I’m willing to accept highly specialized business apps that have their own conventions. Thinks like Blender, AutoCad, Logic, etc.
I’d still like to see them try to match a little, but they’re specialized enough I get that may be a better path.
Chrome? Facebook? Slack? Teams? No.
I’m not saying things need to look like MyFirstWin32App built with VB6 in 20 minutes.
But use the system controls and conventions. Custom colors and layouts can be fine. But if you want to make your own UI toolkit then make your own OS too and leave my computer alone.
> Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.
No app is more important than the OS, and certainly not Facebook (which has no business being an app in the first place). I made a choice when I got the OS, and I like developers respecting it and not chase the fad of the day with poor approximations of the native widgets (text fields that do not support standard shortcuts, buttons that do not behave as they should, labels that do not support accessibility features, the list could go on). Even huge apps like Photoshop or Office get this wrong everywhere.
I definitely agree on the default (use the native toolkit), but there are no applications big enough to get their own behaviour. Open Source or hobby applications get a pass if the UI is a bit wonky, but that’s about it.
> Does Microsoft themselves build their apps this way?
I'm not sure anyone could really answer this question considering how fast Microsoft's various silos pinball between UI conventions. All of them are (I would hope) based on various iterations of their own internal tooling, but looking from Windows 7 to 8, 10, and then 11, you get such stark differences in UI language that you feel like you're looking at competing products.
That being said, I would personally very much prefer apps that are built to mimic the system they are a part of. One of the worst sins of that one, IMO, being iTunes on Windows which has always been and continues to be a flaming dumpster fire for a number of reasons, but most especially it's UI. It is a Mac app that is parked in Windows. It looks like a Mac app, it operates like a Mac app, it's UI conventions are that of the Mac, with the one major difference being they stuffed the window controls in the window in an incredibly slapdash way to account for Windows not having the system bar.
But yeah, for any marketing people here, I have not once nor will I ever give a single molecule of a shit about your brand identity. Make your software good. Ideally make it mesh with the system it's in. I couldn't fucking care less what color everything is.
> and fitting in with the system theme is all you ought to aim for, most of the time
Even Microsoft struggles with that.
Only because they change the system theme every 45 minutes.
Seriously, someone needs to reign in their UI department. No more refreshes until you actually finish one.
Or if you’re making games. All games seem to cherish a unique look even starting from the game menu or title screen.
I, for one, miss customized installers. We've kind of lost out on those what with the move to digital distribution.
Gone are the days of my friend accidentally having his volume cranked when he inserted the Red Alert 2 disc, not knowing it would blast out "WARINING! Military Software Detected!"
My experience with SwiftUI on the Mac is that it still needs a lot of work. Documentation is poor. Performance can be bad if you do things in a straightforward way. Supporting older versions of the OS is quite painful etc.
Documentation remains the number one reason I personally don't make Android apps and why electron/web apps are the way to go for most GUI apps these days.
Unfortunately it doesn’t seem like having good, bug free, modern and well documented desktop APIs is a priority for anyone anymore.
I recently built a small app using SwiftUI. It was my first, and pretty simple.
The documentation was absolutely maddening.. Half the time the Apple docs referred to a previous version. “Do this thing in XCode” often included screenshots of UIs that don’t exist in the current version of XCode. Examples I found on Stackoverflow or random blogs were usually no longer applicable.
It felt like magic when it worked, all those VStack HStack nestings, but the annoyance of finding my way there made me seriously doubt whether I’d build a big app with SwifUI, especially if I wasn’t working alone.
Thanks for the follow-up. These types of anec-data are the best part of HN.
I know the feeling from Qt. I think Gtk and many other GUI toolkits use the equivalent of VStack and HStack to make resizable GUIs. Some GUI toolkits try to avoid this problem by using a grid layout, but it is more rare.EDIT
From your experience, what GUI toolkit would you prefer? And, it would help to know what is your target UI platform.I don’t have much app experience, I’m mostly a back-end guy trying to build some prototypes and (hopefully) one product.
I’m not in a position to give anyone advice, but I’d love to find SwiftUI but cross-platform and usable from anything other than XCode (well maybe not Ed…) and native GUI and a pony.
For my product I need to support Mac, Windows and eventually iOS/iPadOS. For prototypes iOS is enough. I don’t mind learning new languages for this, but ideally there would be some advantage in knowing the language itself. I’ve been looking at lots of frameworks over the past month.
The most tempting thing so far is Flutter, but I have nagging doubts: because it’s not native UI, I worry about that being a no-go for some large customer down the road, and also about alienating power users. I looked at React Native but it’s not very good for desktop yet as far as I could tell (and the demo app from the documentation doesn’t work, which is a bad sign). Which is too bad because I was impressed with Expo, if I just needed phones I’d probably use that. I looked at Avalonia but it has the opposite problem.
Today I’m looking at Tauri for the Nth time: at least I could improve my Rust, and it seems to have momentum. Doing the UI in a web view is kinda sad, though, after trying SwiftUI.
Just building multiple apps is not realistic, I’m a solo dev and want to get this to market in my lifetime, and it only makes sense if I have both Mac and Windows.
Very happy to hear recommendations from people who have done this!
If you really want native look and feel then really your only choice is to use the native toolkits.
I'm not convinced many users care that much about this though. They spend most of their day using apps that don't use native controls and I think they're all pretty used to it by now.
I prototyped a bunch of different desktop toolkits and I think that today Flutter is by far the most polished and mature. I've had overall a very positive experience using it for my music app:
https://plastaq.com/minimoon
The threat of Google canceling it is real though. I suppose if that happens I'll switch to Tauri or just give up on Windows and Android and do SwiftUI. My experiences with SwiftUI to this point have not been very positive though.
Kotlin Multiplatform might also be an option at some point but it doesn't seem that close today. Unfortunately it seems like none of the os vendors are making their desktop APIs a priority these days.
Thanks, I will have a look at that. Serendipitously, I'm in the market for a new music player!
Yeah the Google risk... seems like they came out strong in support of Flutter at their last dev conference, but at the same time it does _not_ look like they're using it for their main apps.
Please let me know if you have any feedback or suggestions for the player.
And yes I’d feel more confident in Flutter if Google was dogfooding it a lot more.
Without expressing an opinion on Flutter as such, it's worth remembering that Google is a big enough organisation that even -some- internal apps being built using it is quite a commitment, and it not having spread further internally could easily be a social or political rather than a technical issue.
I don't think it it's a technical issue. On a technical level Flutter is mostly great. But Google has been doing aggressive cost cutting lately and not having Flutter in use in that many apps makes it more vulnerable.
I’ve had overall very positive experiences with Flutter. If I wasn’t concerned about Google’s long term commitment to it I’d use it for everything.
Did you do cross-platform and if so, did you use the same UI style for everything?
Today I was making a list of reasons/excuses for using Material Design on Mac… which I guess would make some people mad, but it might work for an enterprise product.
Yes cross platform and the same style. I don't think this matters much to users today. They're used to it.
That said I did do a fair bit of my own theming. The Flutter Material widgets are actually pretty customizable and I'm not a big fan of vanilla Material.
https://plastaq.com/minimoon
Yes. Two different things. The SwiftUI docs are mostly just listings of functions and not much explanation of how to use them.
Plus, half of the official examples are given to you as a full Xcode project that you must download and import
He should have used C++Builder. Native Windows widgets (so you get, eg, IME support) but it can theme them. And comes with dark themes!
Edit: and fully static linking. Might be a meg or so.
Dear ImGui is for development/debug tools, not an UI for the end-user. It's great for small projects as long as you don't care about accessibility, or proper keyboard support, or adherence to standard UI conventions, or support for devices without GPUs, proper font rendering, etc. ...
It's also suited to games, where "non standard" UI is expected and part of the experience.
Most games don't use ImGUI, though. Like the parent commenter said, it's useful for debugging, but the actual in-game UI—HUD, inventory, map, etc—is usually rendered by yet another middleware framework like Scaleform, or something that the engine provides (Unreal or Unity).
This is true. There is a reason why Scaleform made its way to become a popular gaming UI framework even though many of its weakness. The most important focus in game UI framework should be on tools and pipelines for artists/designers and this is usually not up to engineering decisions. I won't say that using ImGUI for game is impossible, but there might be lots of tooling works ahead for production game development.
Nuklear is sometimes used. Anyhow, I do know of some game engines created and used by a (very large) game studio that uses ImGUI. I won't say anything else though :)
> I do know of some game engines created and used by a (very large) game studio that uses ImGUI.
It often isn't a secret: https://github.com/ocornut/imgui/wiki/Software-using-dear-im...
ImHex uses it for the entire UI
There is also furnace[0] and mmlgui[1]. Which are recently developed programs that people have been using to create chiptune music for retro video game consoles. Including being used by Yuzo Koshiro[2].
[0] https://github.com/tildearrow/furnace
[1] https://github.com/superctr/mmlgui
[2] https://x.com/yuzokoshiro/status/1800554520256360794
And that's a dev/debug tool, just as explained by OP.
imgui offers incredible development speed. And I've used it many times with great success. It's unorthodox yes (and there's a long-open bug I won't talk about again) but it's dear to my heart. It's like MFC on steroids: You don't have to leave C++.
But yeah at least a few of those caveats remain. Although keyboard navigation and font rendering have quite a bit of support.
Due to what reasons does imgui offer incredible development speed?
Because adding a text is just a imgui::text("abc") function call. And a button is just an if(imgui::button("click me")) do_something() statement. There is no other language involved, no markup, no gui editor. Just direct code and highly hackable to make this extend to unexpected lengths.
Thanks, got it.
To add to this, I find it easier to have a simple while loop that renders the screen, fetching variable data on-the-fly, etc. It is rather pleasing to the eye to understand the layout with IM interfaces, etc.
Comparing this to (something like) WPF, you create XAML files, with either or combination of ViewModels and back-end code to "bind" and can get complicated quickly. I guess the only exception to this is if you have commited to WPF non-stop for many months. However, with IM interfaces, its easy to get going (imo)
I currently see two international keyboard issues:
- French Keyboard and Backend SDL2 - Several keys are not checkable with IsKeyDown
- Wrong ImGuiKey keydown indexes reported from Win32 backend for some keys when using UK keyboard with UK keyboard layout
There are also 2 issues with IME:
- Marked Text / SDL_TEXTEDITING Event / IME Composition support
- Backspace handling by text widget in default Windows IME environment.
Excellent reply. I did not consider international keyboards when I writing my reply. And gaming companies are definitely targeting international markets in 2024!
Agree. "Single executable" combined with "less than 40mb" is just looking for trouble for what the author is trying to do. If you want to do win32, go ahead and give up styling. Otherwise, make compromises. I think many of these are excellent choices chosen by many programs that I use, it's the author's stringent requirements and unrealistic expectations that is holding back.
This comment makes me feel like I live on a different planet.
In 1999, I built a completely custom Win32 GUI for a (brandable) chat application - that was the product the company I worked for was selling.
Pure C and C++. It was a 32-bit app, not 64 bits. And we felt bad for it being 250KB single executable (skin included in resource section) and not “150KB or less” as was our initial target. But making it accessible and fully skinnable/themable/l10n/i18n did add quite a bit which we hadn’t realized when thinking 150KB was realistic. But it’s not like we resorted to any crazy tricks; that was just the stripped linker output.
It was still a reasonable download at the dominant dial up internet at the time (28.8Kbps IIRC)
Sure, modern tools add a lot of cruft that you’d have to work hard to reduce, but 40MB. Oh man.
> In 1999, I built a completely custom Win32 GUI for a (brandable) chat application
Given that it’s windows, it might still run today, so it likely is still possible
> but 40MB. Oh man.
It is perfectly fine to build a 150KB or less executable today. But then OP decided they don't want to write paint functions for custom GUI and insist on finding a library to do so, I guess that's not what you did in 1999, right?
I actually used FLTK for the first iteration; The theming support it had at the time was not sufficient, though, and the i18n story non existent (that was before even 1.0, versions were still labeled by dates).
So, because pervasive theming/branding was a hard requirement, and i18n a softer one (every skin has to only support one locale), i had to abandon FLTK. But FLTK did spoil me by providing seamless flicker free double buffering out of the box, which I insisted on implementing in our gui.
For those of you who don’t remember - Win32 flickered badly on almost all screen updates, window resizes, etc — I think that was generally true of most apps until 2010 or so. FLTK was essentially the only GUI toolkit at the time (1999) that had no flicker out of the box.
There's another way to build a 150KB or less executable today. Mime is less than 90KB, have a look at https://webd.cf/webd/ It's a web file manager.
My app is around 500 KB (not megabytes) and it supports dark mode (see https://www.abareplace.com/). So this is definitely possible without using Electron or bloated GUI libraries.
Winamp comes to mind as a counter example.
IMO, every media player since Winamp 2.x has been largely a step _backwards_ in pretty much every metric one could put forth. It was light-weight, using minimal CPU & RAM. It was skinable. It was reliable. It had great plugin support. I don't recall it leaking memory, either. I basically had it set to auto run on login on my PC. I never closed it. Didn't need to. I had _only_ 32MB of RAM on that computer.
+1.
I still use Winamp, and essentially in its 2.x mode.
Qt makes such amazing apps. I love KDE and the apps they spawned like Kate, KDEnlive, Krita.. It's no wonder their apps are so popular on Linux and windows alike. Unlike GTK apps even though it does have bindings for Windows.
> he didn't want to pay for a license
Well that's the killer right there. I too think it's way too painful to write Windows UI, especially if you want to stay away from Electron (which you should in almost all cases), but refusing to pay money for good software is going to severely hamper your goals in 99% of cases.
> stay away from Electron
Is this really still true though? VS Code and Slack are all quite polished and give me no issues as a user. Not sure what else I'd consider to build something similar.
I might understand polished, but no issues sounds odd. What about the abysmal performance? Also most folks building things do not have the resources that Microsoft has, so I believe VSCode is not a good represantative of most Electron software.
If you’re on windows and want a “standard” guy, either use the .net GUI or Qt , if you want completely custom and willing to do the work use QML or ImGui (or variant like eGUI)
Which particular .NET Gui? There is a collection of them: MAUI, WPF, Blazor Hybrid, WinUI.
Microsoft have utterly screwed the pooch on getting their .NET GUI story straight.
In my opinion, WPF is the logical choice. Still.
Probably Windows.Forms unless there’s a REALLY good reason to do anything else.
Don't forget Avalonia. Looks like it's going to be the sensible WPF version.
WinUI 3 is the default for Windows-only applications
Nah, it is so bad, that on BUILD 2024, they have brought back first level status to WPF.
No one burned with WinRT history since Windows 8, is ever touching WinUI, unless they are Microsoft employees on WinDev, or companies with sunken costs trying to keep their products around.
Win UI 3 is the worst kind of improvement because there's arbitrary equivalence between WPF concepts and WinUI concepts, not a 1:1 equivalence. WPF as the mature stable model should be gospel; you don't re-write the gospel. Yet Microsoft feels they should re-write this gospel because... it aligns with the vision (???). Both use XAML, but the concept of DataContext is substantially changed, the concept of bindings is substantially changed, etc. Why make every XAML attribute ever-so-slightly different? Are those changes really an improvement? A lexical improvement? A performance improvement? Or just baggage and overhead to learn?
Compare Microsoft to OpenGL. Boromir says "one does not simply change the OpenGL API..." Microsoft does not have nor ever had OpenGL level of API with their UI frameworks. I guess you could say WPF is maturity in age only but doesn't represent conceptual maturity.
With the differences, you basically throw away all the knowledge of WPF to restart in WinUI, and with poor documentation. The documentation is there, i.e. the "what" but the docs should be primarily "the why and how"; how to map WPF concepts to WinUI3, which is arguably the more critical documentation to provide, and currently pitifully poorly documented.
Doubly so because it would help indicate a measure of feature equivalence; does WinUI 3 currently represent feature equivalence to WPF? Has XAML Behaviors been integrated as a member of the API?
Except it's still missing a lot of controls, further development and bug fixes are practically at a standstill, and despite what TFA says, there is no visual designer support (which is a dealbreaker for many multidisciplinary teams).
As someone currently involved in switching our app from MFC, I really want to like MFC, but Microsoft's absolutely addled management of the whole thing is making it really difficult.
Title is "Writing GUI apps for windows is painful", and then the author slaps on a bunch of bullshit constraints but pretends to be covering the general case. Sorry dude, if you want to do that then change the title to something appropriate like "Writing small, custom styled GUI apps for windows is painful". Otherwise this is bait and switch.
Implicit (for me anyway) in the title is that you are talking about vanilla GUI apps. Writing vanilla Windows GUI Apps is trivial and there are a bunch of tools that handle this extremely well. The article covers many of them but chooses to disqualify them for reasons.
Then we have ImGui as the tool of choice, but now this is qualified as only for "simple apps". Really? After all the fuss about constraints not being met? A bit of cognitive dissonance here I think.
More complex functionality things can get difficult but often even these are handled depending on the tools.
For vanilla dev the clear winner in terms of productivity has to be WinForms. Or if you can live with the clunky IDE - Lazarus. (You're allowed to replace with your own favorites.)
The real challenge is not writing GUI apps for windows, but rather is in writing cross platform apps.
"Writing small, custom styled GUI apps for windows is painful"
I'd add "for free because I'm too cheap to buy a license for a toolkit that does what I want".
> This is a good overview of some of the options, but the author’s specific requirements push it in a specific direction that eliminates a lot of options.
The blogger sounds like they put up a bunch of arbitrary constraints that in normal circumstances wouldn't even be issues.
In the process it's those arbitrary whimsical choices that reject the very obvious choices along with any happy path.
For example, it's baffling that there are already a few FLOSS forks of Qt out there, but the blogger failed to cover them. If the author likes Qt so much, those would supposedly be the obvious choices. But no.
Once again, you are left out of options if you go out of your way to avoid each and any option.
Isn't the issue with Qt exactly what the GPL intended?
In that case, any Qt fork would force him to also comply with the GPL, and supply the source code of his project.
LGPL. Which eliminates his requirement for a single executable. With LGPL you are only allowed to link dynamically.
Not true at all. The LGPL does not specify anything about mode of linking or anything like that.
What the LGPL requires is that the end user be able to take the source code for the LGPL part, modify it, recompile it, and then replace the functionality in your binary provided by that part with their new part.
Obviously with dynamic linking this is almist trivial, the end user replaces the so or DLL and done.
With normal static linking, it's only a bit harder. If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.
> If you ship alongside your binary a bundle of eg .o files
You might even be able to use partial linking (ld -r) to ship a single .o file instead of a bunch of them.
The linked post does mention that:
> or distribute object files for recompilation
> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.
This is super clever, I love it! Does any software actually do this?
Yes. For instance some Cisco app on iOS that uses gstreamer (LGPL) does exactly this.
Do you mean iOS the iphone operating system, or cisco IOS the router operating system?
> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.
Do you need to ship it alongside or produce it on request or link to where they can fetch it? It's not like you need to ship source code alongside either for GPL binaries.
Cool!
Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.
I don't see why not. So long as the LGPL part can be modified and replaced, you're good.
I am not a lawyer.
I mean, if you're willing to do that why not just dynamically link?
The OP article is saying that static linking leads to size reduction. That's why asking.
You’re not getting a size reduction if you maintain a library boundary, though. What you’re doing is isomorphic to dynamically linking except the app code is in the library and the library code is in the main binary.
Ok. I understood. Thanks for explaining.
The goal of this is so that end-users can modify or update Qt, the LGPL licensed component.
The LGPL is working as intended.
Yes. But the article states that they don’t care about that. They just want a single executable.
I never understood the need for a single executable on windows when folders, zip files, and 100% free installers exist if you don’t like zip files. Also nearly all of the gui kits he’s shooting down have ways to build custom components if that’s what you want to do.
None of these help you if you are dealing with users that move executables for convenient access or think updating the sofware just involves dragging and dropping the new executable into the existing installation folder. Customer support had countless stories like that.
Does using something like APE by jart work? It's a single executable that's also a zipfile. (I assume a replaceable .dll inside the archive is LGPL compliant) I know it's a bit of a tangent, but on platforms like macos the "apps" are all directories with the .app extension, and that doesn't seem to cause issues.
No need for an installer when it's just one file you can run anywhere. And folders/zips are way too hard for the average user. Ask me how I know. My partner gave up an entire game platform because it was delivered as a .7z file they could not figure out.
But a .7z requires a custom expander, .zip is natively supported by windows, isn't it?
.7z recently got native support.
Then pay for a license or make the object files available to users who want to relink the app.
CopperSpice is LGPL, not GPL.
It's not a problem.
Hmm. How could that be when it's based on Qt?
Qt is also available under the LGPL. There is no license advantage to using CopperSpice. I'm not sure what GP is referring to.
Some parts of Qt are GPL only.
True, but they are optional and are not the parts you need to create a GUI as per the requirements in the OP. I assume CopperSpice does not include these components.
Yeah, I can confirm that writing windows GUI apps is not at all painful for me. I still use Windows Forms in .NET 4.8 and my executables are < 1mb, Visual Studio's form designer is very easy to use, you can subclass all the .NET UI controls and customize them however you want. There's always been accessibility and even support for high DPI.
>I still use Windows Forms in .NET 4.8 and my executables are < 1mb
Do you need to ship any supporting files separately, along with the app?
And is .NET 4.8 or higher already on Windows PCs?
.NET 4.8 is the last .NET to be bundled with Windows. It's a legacy stack, but it exists on every Windows >= 10 so it is a legacy stack that makes deployables easy (just assume it is installed). (.NET 4.8 is the new VB6.)
With .NET 9 right around the corner, how far behind the legacy stack is only increases.
.NET > 5 will never be installed out of the box on Windows PCs. The trade offs to that concession however are: cross-platform support, better container support, easier side-by-side installs support ("portable" installs). .NET > 7 can do an admirable job AOT compiling single-file applications. For a GUI app you probably aren't going to easily get that single-file < 40MBs yet today, but it's going to be truly self-contained and generally don't need a lot of specific OSes or things installed at the OS level. Each recent version of .NET has been working to improve its single-file publishing and there may be advances to come.
A nice thing about .Net Framework 4.8 is that they finally finished it! No more update treadmill and dicking around dealing with what versions are installed or how to configure your application to use whatever different versions. Just target that and forget about it.
.NET 4.8 is default in Win10/11 now.
Thanks, guys.
Agreed, this is a bit like writing ‘developing iPhone app is painful’ but not using anny officially supported tooling.
fact that you must ship the app Unpackaged is particularly strange.
Are you saying without an installer, or unpackaged as in without a package identity ala https://learn.microsoft.com/en-us/windows/apps/get-started/i... ?
40MB seems like a weird requirement. If it’s under 1GB, I don’t think most people really care any more about executable size. Memory usage is still relevant, but 1GB is going to be less than 1% of disk usage for almost everyone.
1GB for each app accumulates really quickly. 40MB is really low, but I wouldn’t be happy with 1GB per app personally. Anything below 500-600MB is fine.
I want my disk space for large medias, not for a desktop app
I've gone through the same process of evaluating x-platform alternatives and I can now understand why Electron is so popular.
I mean, you do have the unreasonable bundle size, but other than that you can make really good looking applications using the same tools you can use to make web sites for both desktop and mobile.
I've been eyeing https://neutralino.js.org/ since if I'm going to make the app render right on browsers then relying on the same code via webviews likely isn't (much) more portability effort.
[dead]
I have a very low opinion of developers who decry having to pay for a commercial licence for otherwise LGPL licensed software libraries. They expect to be paid for their work, and ensure that by creating closed source software. That's fair enough. Yet, the devs that solved the actually difficult parts of creating a UI library have to be utter saints who freely bestow a gift of code upon the world.
I think his complaint is not that he has to pay money per se, but having to pay several thousand dollars. That's a bit much for an independent developer.
I have little sympathy for that kind of argument, imagine a carpenter complaining that they have to buy wood and nails. Besides, a Qt license for small businesses is nowhere near thousands of dollars. Only in software development do we expect quality tools to be given to us free of charge with no strings attached.
Qt for Application Development Professional (ADP) is 3460 €/Year.
If you're making something which you sell for $50 or so you'd need 100 sales per year to just pay for the development environment. That also assumes that it took you less than a year to make said product.
'Qt for Application Development Enterprise - Small Business (ADE-SB)' is $499.
You're right. I didn't see the Small Business tab when I was quickly looking through it.
Still ends up being a blocker when you're not sure how many copies of the product you'll sell.
I guess that is just one of the many risks you have to take if your trying to build a business. A couple of hundred dollars in licensing fees are not going to sink your product. For a side project that you don't expect to make any money it might be too much, but in that case you could just as well open source the project.
> but in that case you could just as well open source the project.
Which doesn't necessarily mean you cannot get paid for it.
It's also worth considering that the value of this license is very likely not a net loss even if your initial product doesn't work out.
Your take is very weird.
He's shopping around. When something is out of his budget it's natural to not buy.
wood makes sense to pay for. wood doesn't grow on trees. software works a bit differently though it should also be paid for
It's especially hard when the application you're building isn't yet proven. As there's no guarantee that it will get any sales, let alone enough to cover the Commercial Qt expenses.
You do not have to pay before your first sale.
And $500 is laughable small compared to developer salary. If it saves you half a day of work, you are covered
There is a huge gulf between saving a half a day of work versus _having_ $500 to spend on a tool that would save you that half day of work.
Exactly this.
Qt is amazing, so if your requirements are so strict in terms of space and you know/like Qt, investing in the license, or make the product open source, shouldn't be an issue here.
Agreed. Also didn't get why he felt complying with the terms of the LGPL for a statically-linked .exe would be so much of a problem. Just put the object files and build script in a zip file, and upload it to the same webserver where you plan to put the program. Add a line in the "About" dialog (or whatever) pointing to it. Done.
Whilst I don't understand the users who are hell bent on having a single-executable work, if you have users who are hell bent on using but a single executable, you have to meet them where they're at.
In my experience Windows users don't care about the statically linked part
What they care about is having an executable and not needing a zip with dlls
And that is trivially achievable by bundling the dlls into the exe file
Also trivially achievable by making an installer instead of shipping separate files. People are really used to that pattern.
No, it makes perfect sense to complain about paid software libraries because it inevitably makes getting to them a huge pain in the ass and that causes folks who just want to easily give the library a try every reason to go try something else. Then as a result the ecosystem of apps using sad framework begins to stagnate.
Yes, closed source libraries are a pain to work with. This is why I like the GPL/Commercial dual licensing model. You can try it out for as long as you like, have full access to the source code and can even create commercial software for free. You are only required to pay for a license if you want to create closed source software. I consider this an absolutely fair deal, yet the blog author seems to take issue with that which is what I am criticizing.
That’s fair in theory, but it really feels that they’ve made it more difficult to find the open source version of Qt last I checked. I haven’t tried to use it in a while, but I recall last time I tried I just gave up.
Unfortunately they do and they really try to scare you away with the GPL boogeyman. It is a fair criticism. I would recommend to ignore the installer entirely and rely on a package manger like vcpkg, conan, apt, or brew instead.
You can find the manual installer here:
https://www.qt.io/download-qt-installer-oss
While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret.
Also the single exe deployment, while convenient at times, is perhaps not worth the hassle in this scenario. Using a packager like Velopack (squirrel) makes it a single exe to distribute and as an added bonus makes it self updating. That it has two or more files on disk when installed seems like a good tradeoff.
Windows is the worst platform to develop desktop apps for, apart from all the others.
> While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret.
What I find the most mind-numbing thing about the blog post is the way WinUI3 was excluded. WinUI3 looks like an exact match for the blogger's most critical requirements, specially the customization thing, and there is absolutely no better way to target Windows than Microsoft's official GUI offering, but somehow that one is rejected? Absurd.
WinUI3 is a can of worms that’s becoming palatable only with .NET 8 (and soon 9). In a normal configuration, you have to bring 500MB of dependencies with you, or ask the user to install a redistributable. You also need the user to install .NET 8, or bring said 0.5GB with you.
WinUI3 can be used in unpackaged apps (I.e.: not appx) but has a few random caveats that just don’t work; random APIs that have a footnote of “oh this doesn’t work in unpackaged apps” or “works in unpackaged apps but only in .NET Preview something-something”.
.NET 8 fixes a lot of this by adding AOT compilation and single-binary releases, but it’s still fairly large. .NET 9 then improves culling of unused framework code from your published file, and also adds WPF -> WinUI3 theming support.
Source: my repeated attempts to rewrite our product’s UI in WinUI3 (from WPF on .NET Framework 3.5) several times.
I don't understand why Microsoft puts it on the user/dev to make sure their own dependencies and "VC redistributables" are installed.
Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library.
Feel I always hit a roadblock when setting up a new PC where one of the things needs that but the dev didn't provide it and I have to get it myself. Which feels weird when it's an official MS thing from their official dev tools.
Microsoft's solution to DLL hell was installing lots of DLLs side-by-side. The problem with WinUI and VC redistributables is that we've now got a combinatorial explosion of them and teaching an installer to know and understand the complex network of dependencies is a lot of work.
Microsoft's intended solution to this was to write one last Installer platform to try to rule them all. That's where AppX and MSIX installers came from. Unfortunately for us all, that Installer platform was synonymous with the Windows Store/Microsoft Store for just long enough that everyone assumes that is all that AppX/MSIX were intended to be. Today MSIX supports everything you want to do in a Win32 application, plus all the Dependency Fu of getting a WinUI application correctly installed. Just about the only left that you can't install directly in an MSIX is kernel-level drivers and even then there are options depending on your hardware vendor relationship with Microsoft.
The article dismisses MSIX packaging out of hand, but given it is still referred to as AppX packaging in the article, the author might not be aware of how much MSIX packaging has advanced in a bunch of years and still makes some assumptions of MSIX limitations based on early Store-intended AppX restrictions.
> Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library.
In this day and age of everything always connected, some things still aren't always connected.
The app manifest could state "I need this runtime installed". The OS can know whether it is already installed or not. The OS also knows whether it is internet connected or not. If a runtime that isn't installed is needed and internet connectivity isn't available, the OS could state that, with information about how to procure the runtime manually.
That would stop people that have copied thr application from a pendrive in an air gapped system, that's true. One could make the case that someone meeting all of those requirements for would be technically minded enough to figure it out.
This wouldn't help developers who want to distribute a small application that won't ever require a download, but would be an improvement for anyone already distributing .Net applications over the web.
The OS presumably also knows where I should get it from as the same company hosts the installer as ships the OS. Yet IIRC the error is just an obtuse thing complaining a DLL isn't there and through googling and hopefully finding your way to Microsoft.com not some malware site you have to find the installer yourself.
Mild annoyance for someone with 28 years Windows experience, complete roadblock or malware vector for someone who just wants to use a computer rather than understand a computer.
What kind of build settings lead to 500 MiB binaries? I struggle to imagine something that could make the toolchain to emit such a large binary save for select degenerate cases of runaway generic specialization when you AOT compile an SDK that combines LINQ with 2102718201 enum types, all of which get their own set of generic instantiations for every internal iterator within LINQ - that's a known issue that is fixed by enabling identical method folding in ILC, the worst offender used to be Kiota OpenAPI generator causing this, but thanks to tireless work by Filip Navara that was fixed there.
In general, there are quite a few knobs for configuring how exactly you would like to have your application published. This is also an area of active improvement with each new release as you noted. It is very worth it to look into further build configuration nonetheless. If you still face an issue with "this surely shouldn't take this much space", it might be a good idea to submit it to either https://github.com/dotnet/runtime or to the repo of the GUI framework depending on where you think the fault lies - without feedback it's difficult to know if there is an area that needs improvement or a known improvement opportunity that has demand.
WinUI3 itself.
If you want to be "normal", or at least follow the Microsoft semi blessed path, and make an appx, that does not include WinUI3. The user installs it, and in the process pulls down WinUI3 (also an appx) if it is not already installed. It's only if you really insist on "self-contained" that this problem arises.
I say semi-blessed because of course Microsoft aren't really committed to WinUI3 and barely any of their own apps use it.
It’s just because the WinUI3 libraries and/or .NET Core runtime take that much. Mostly WinUI3 IIRC.
And that’s when you use “selfcontained mode” rather than AOT publishing, now with AOT it’s considerably better.
Self-contained/single-file mode is compatible with trimming and benefits from the work done to improve AOT story. As AOT binaries get smaller and ILLink's analysis gets smarter, the single-file trimmed binaries will see a part of such improvements.
The issue is that many GUI frameworks are not AOT-incompatible per se but rather trim-incompatible as they rely on reflection that is done in a way that is totally opaque to ILLink save for rooting everything.
You can try the following publish option anyway, and in many instances it "just works" (assuming .NET 8 SDK):
Note: trimming was introduced in .NET 6, and NativeAOT was initially introduced in 7, so it had seen quite a bit of work to mature and improve by the time 8 shipped.If only UWP had a AOT compilation story for .NET code that could be re-used for WinUI 3.0....
And then there is the whole C# / C++ interop between CsWinRT and C++/WinRT.
You should browse the set of WinUI related repos, YouTube community calls and Developer Connection, feedback is something they aren't short of.
Anyone that has used WinUI since its inception, knows that the best for our sanity is to avoid it at all costs.
It is still years away to provide feature parity with UWP/WinUI 2.0, let alone the Windows Forms, WPF capabilites and Visual Studio tooling.
Using it from C++ is only for ATL / VisuaL C++ 6.0 die hards.
Some of the issue is he has outdated understanding of AppX packages (MSIX). You can use all of Win32 from an MSIX package, and all of WinRT, and WinUI3 etc. It's actually the other way around: there are some Win32 APIs that only work if your app is packaged.
Agreed. I had the exact same question.
From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code)."
I don't understand what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it.
C++/CLI is managed code, it’s basically C++ compiled into .NET IL.
If you’re writing C++ code running on .NET / .NET Framework, you’re basically writing masochistic C#.
But why even use C++ for the front end if it’s going to be .NET? Managed C++ is mostly useful as a shim, not as a platform language. It’s not really an alternative to C# on the .NET runtime but just some C++ extensions for interop with it.
If you make a WPF/WinForms frontend then that should be the exe entry point, and that would likely be managed. Then your business logic would be the auxiliary DLL (which can be embedded into the managed exe). There could be a layer of C++/CLI between these to layers (C# front end and native backend) because it would make the interop a bit easier than having to do C-style interop.
> But why even use C++ for the front end if it’s going to be .NET?
Because the author of the article wanted to use C++, I don’t know why. That’s why I called it “masochistic C#”.
Actually I find it much easier to write C++/CLI, than getting right all P/Invoke marshaling, specially if COM is also part of the picture.
Also C++/CLI can also generate native code when specific code patters are used, that is why there are some compiler flags to disable it, and such assemblies are considered unsafe.
> I don't understand what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it.
I don't think the author is talking about interop here, but rather the fact that GUI front-end code written in C++/CLI still ends up being managed rather than compiled to native code. I suppose the author insists on the front-end executable being nothing but a PE x86-64 binary without any runtime/GC embedded in it, pure native code.
That insistence isn’t motivated in the post in any way, which makes it a really weird and arbitrary requirement.
Same here. People are confused because the author gave two options:
And then a single "problem" paragraph that didn't make it clear which problems go with which approach.Reading many of these comments makes me realise that the whole premise is flawed. I "vote" to rename this blog post as:
They should try to target .NET Framework 3.5 using WinForms. That is my best suggestion, as all recent versions of Windows will have this installed (at least)..NET since 6 (I think) can be published as a self contained app with the runtime included.
It immediately adds some size to the output but you can mitigate it with AOT and trimming.
AOT is currently only available in CLI apps. It's expected for WinUI 3 apps using WASDK v1.6 closer to the end of the year.
Not limited to CLI (even at release in .NET 7 it was possible to use it with ASP.NET Core with limitations and there were custom templates to make it work with some GUI framework I think, and MonoGame already worked partially), certainly not in .NET 8. I’m not sure about WinUI 3 itself, but a lot of things today are AOT compatible.
And naturally single-file + trimmed works almost everywhere, in some situations requiring to add attribute annotations for un-analyzable reflection usage patterns.
"Single file" has the annoying property that it unpacks all your assemblies at runtime and dumps them in a temporary directory. There's no good reason it couldn't byte-load them directly out of the executable instead.
Do you mean IncludeNativeLibrariesForSelfExtract attribute? This is a related but still separate feature. If you mean the managed assembles, then it works differently:
"Only managed DLLs are bundled with the app into a single executable. When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder. With this approach, the managed binaries are embedded in the single file bundle, but the native binaries of the core runtime itself are separate files."
https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
For """embedding""" native dependencies into the binary without self-extract, you can't really do that, the closest alternative is statically linking them into AOT compilation instead (but that gets tricky with large dependencies).
Windows Forms is also making some progress on being fully AOT compatible:
https://github.com/dotnet/winforms/issues/4649
Oops, I googled it and you’re right.
No go for net 4.6 which is installed on every currently supported Windows version back to the original Win10 released almost a decade ago.
There are still people running Win 7 but I wouldn't worry about that group having a streamlined experience. With 4.6 they can still install the runtime manually.
Why 4.6 and not 4.8? (I assume you mean .Net Framework and not .Net.)
4.6 instead of 4.8 because 4.6 comes preinstalled with any Windows (Any supported Windows that is, i.e. Win10/11 or equivalent server), so from the user's perspective it will be a no-dependency app, just like a Win32 app.
Anyone reading this thread will surely roll their eyes and move on to a different solution. Event the people who recommend this stuff to others get confused about what the fuck is even happening in the .NET ecosystem.
It was pretty simple up until the whole netcore fork and netstandard confusion. Then it was confusing for a number of years. And now it's actually pretty simple again.
The naming of ".NET" and ".NET Framework" is confusing as hell. But basically Microsoft is hellbent on launching something completely new and having that take over the .NET name, even if it means years of confusion.
.NET Framework 3.5 is no longer installed by default starting with Windows 10.
The reason why I suggested 3.5 was to include a long line of compatibility with older versions of Windows. And, correct me if wrong, a binary compiled with / targeting 3.5 will still run on 4.8
The requirements are not just unrealistic, but, you know, wrong?
> It is extremely hard to stylize native Win32 controls.
Yes, it should be! I know Microsoft is errant in its ways itself, but controls should not be custom, they should be standard.
As of Sciter and "antialiasing" issues mentioned in the article...
Author did not enable high-DPI support in his/her application. As simply as that...
Either in Visual Studio : https://sciter.com/wp-content/uploads/2024/06/high-dpi-aware...
Or by including proper manifest: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/d...
That actually is explained in "Hello C++" tutorial: https://sciter.com/hello-cpp-tutorial/
Sciter desperately needs an evangelist who can reply and help people with their problems and just in general provide support and work on the ecosystem. I think from what I remember from indiehackers you are not there yet to be able to afford it but we desperately need that.
Even paying pravic to keep the libraries for different languages up to date would be of great help.
Sciter's support forum is pretty active : https://sciter.com/forums/
Mr. Yuri (Pravic) has his own agenda these days. As far as I know creation of Go, Rust and Python backends for Sciter was a method for him to determine best frontend technology for his organization.
If someone wants to take care about Go, Rust and Python wrappers - let me know.
Ultimately as a user / customer I dont care who maintains the bindings I need to use to achieve my goal.
1. These wrappers are Open Source.
2. I do not have customers that requested either one of these wrappers.
3. Customers that do use one of wrappers, as AdGuard for example, maintain their own version of Sciter/Go: https://github.com/AdguardTeam/go-sciter
What kind of license do I need to buy for the bindings to be updated?
As with any other Open Source project - contact its author and discuss with him/her.
Might end up being yourself.
I'm working on a GUI toolkit that should match the requirements: Slint - https://slint.dev Can be compiled statically in a single .exe that is smaller than 40M. Has a license that allow proprietary on desktop for free. Has dark/light styles. Even comes with a (work in progress) drag and drop WYSISYG editor.
Where did the idea come from that starting with a 40MB exe is small? That's completely outrageous. You could embed all of python, tk, fltk, wxwidgets and pyqt and still not be close to 40MB.
FLTK static binaries start at 100KB, win32 binaries can start at 1KB, Juce is about 2MB.
Using GLFW or SDL for an openGL window then using IMGUI would start at a few hundred kilobytes.
What are you doing in there that makes your binaries 100x times as big and why would this be a selling point?
OP said less than 40MB. You can build Slint binaries targeting embedded devices. So a few hundred KB for a small application. Still arguably too much space but gui frameworks like slint use a domain specific language that generates more verbose code than what a human would typically write. Probably in the interests of being generic.
Man, as a C# dev, I'd kill for a single exe output. The binary being only 40MB is an absolute fantasy.
We have a project at work, it's nothing crazy, mostly shuffling data from one pipe to another, maybe a few thousand lines of code. A true standalone build including dotnet is over 180MB. The build that relies on the system dotnet install is still over 50MB. It's not even a GUI, it's a background service.
Things on Windows have a bad habit of enormous binary bloat, I'm not sure why. I don't think the problem is near as bad on Linux in general, but I don't have enough experience with linux dev to really say
This has been solved since .NET 6/7 and the results should pleasantly surprise you:
- https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
- https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...
Alternatively, you could try the following first (use .NET 8 SDK):
Also, I just tried worker template (it includes generic host, DI, logger, etc.) and it's only 5 MiB when AOT compiled on macOS: Will likely take less on Windows and Linux.You already have that as a .net dev.
I deploy my asp.net site to Linux by building it as a self contained single file. Deploy services. Have a couple of WPF apps both self contained single file.
They all end up around 43-85mb. The services are smaller when trimming is applied at around 30mb.
Not a single project has ended up over 100mb but I can see that happening if you have a ton of nuget packages.
I don't know for certain but expect it comes from comparing solutions with those based on virtual machines like Java's. The requirements in the original article look like a corporate wish list.
I've been evaluating GUI frameworks for rewriting the editor of a cross platform (Mac Windows Linux and web) game editor I maintain, and this looks worth a shot, thanks for sharing here!
I want to move away from the ancient allegro GUI we use, and so far have evaluated ImGui, RmlUi, and Qt, but so far not totally sold on anything.
> Can be compiled statically in a single .exe that is smaller than 40M.
That's... quite a high bar. Last I checked even a QML app was only like 20 MB. Why so big?
40MB was the criteria coming from the article. But it's much smaller than that. I don't have the exact number in mind. I'd say much less than 20MB.
Thanks for the link, slint looks really interesting. As someone who's never made a GUI app would you consider it an "easy" task to make one using slink? Also I didn't see any results when searching the documentation for titlebar, is there any way to theme or change it using slink? TIA!
I'm going through the documentation right now, and I'm a bit confused. How would I integrate it to use for the WInforms UI?
Wasn't it mentioned in an HN post or comment somewhat recently (like a few weeks ago)? I think I saw it then, and checked out the site and a few demos at the time.
[flagged]
There must be some confusion. This is not a web framework, it is a compiled framework with API for several programming languages (including C++) and no HTML/CSS.
[flagged]
From https://news.ycombinator.com/newsguidelines.html: "Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that.""
I realize project != article but the same point applies.
Note that if by following that guideline, your comment gets "shortened" to the empty string, the implication would be not to post. More helpful, though, would be to supply some specific information.
shrug
I acknowledge your comment, and I'm aware of the guidelines. I'm not the only one who questioned their response, so I don't feel particularly off balance here.
Oh I'm not saying your underlying point was wrong or bad! It's a question of how you express it. If it pattern-matches to a snarky internet dismissal, that makes it a bad HN comment even if the point is right. That's because readers will react more to the pattern-match than anything else.
It's even more important to follow the guidelines when your point is right, because if you don't, then you give readers an extra reason (e.g. snarky dismissal) to discredit the truth (i.e. your correct point) and this is a bad deal for everyone. Past explanations in case helpful: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor....
p.s. I don't think what you did was so bad and the length of my response here is just because I think you might find it interesting. It's not meant to pile on criticism.
Writing GUI apps is painful period, and it’s become more so not less in the last two decades.
Go back in an emulator some time and try Visual Studio or even old Borland from the 1990s. Point, click, add code, set style, and the result was not bad at all. The whole UI looked consistent too with uniform controls, shortcuts, etc.
Today UI apps use 100X more memory, are slower, and are harder to use with little to show for it in terms of improved functionality. The whole desktop is a disaster of conflicting designs and accessibility or uniformity are practically gone.
Mobile is kind of shocking too. Here was a chance to dump cruft from desktop and do things better but the result really is just as much of a pain in the arse if not more. Consistency is a little better but the developer experience is awful and of course unlike desktop you really can’t develop on the actual device. That adds another layer of shit.
Say what you will about VB6 but it was stupid simple to get GUI apps up and running.
It was stupid simple to get simple GUI apps up and running. More complicated apps were impossible. But, I think that's exactly what's missing in the Desktop GUI market right now. Webapps are incredibly easy to start apps with. You only need to know a few things and you can pick up the rest later as your app gets more complex. Modern desktop GUI systems are incredibly complicated, in comparison, just to open the window, let alone put text on the screen.
Later versions of Visual Studio with custom controls and other abstractions made fairly complex GUIs entirely doable and still pretty fast to build.
Then they shit canned everything for Xaml around the same time the whole industry abandoned any kind of WYSIWYG or rapid development technology.
> Today UI apps use 100X more memory,
Larger memory footprints aren’t just from the GUI. There is a lot more functionality to deal with everywhere. Just handling modern security, encryption, and certificate checking stack can take up more space than entire executables from the early 90s.
I also have literally 100X more RAM now.
> are slower,
Im fairly certain everyone who says this has simply forgotten how slow mechanical hard drives were. I occasionally have to pull out a very old laptop, hope that it still boots, and do something on it. Everything is so painfully slow in ways I forgot about. It’s refreshing to return to my modern PC.
> and are harder to use with little to show for it in terms of improved functionality.
If you don’t think modern apps have more functionality, I don’t know what to tell you.
I assume OP means slower on like-for-like hardware, rather than slower when run on a PC from the 90s, but to be fair the WinForms/WPF component of old GUI's was very fast even on legacy hardware.
Your profile doesn't list your email, so I'm posting here... is this the paper you were looking for? https://depts.washington.edu/acelab/proj/dollar/index.html Your original post for context: https://news.ycombinator.com/item?id=26152600
It was!! That’s absolutely amazing, what a surprise after all these years :)
Many thanks for hunting me down in some comments!
Awesome, I'm so happy to hear that!
> There is a lot more functionality to deal with everywhere. Just handling modern security, encryption, and certificate checking stack can take up more space than entire executables from the early 90s.
What does this have to do with bloated GUIs?
> Im fairly certain everyone who says this has simply forgotten how slow mechanical hard drives were. I occasionally have to pull out a very old laptop, hope that it still boots, and do something on it. Everything is so painfully slow in ways I forgot about. It’s refreshing to return to my modern PC.
I remember 98/XP running circles on mechanical harddrives compared to modern PCs on ultra fast SSDs. The fact that despite thousand times faster hardware we have slower performance is disgusting.
> If you don’t think modern apps have more functionality, I don’t know what to tell you.
Care to provide an example what modern applications have that older ones lack? Except for always—on connection and artificial bullshit imposed by modern OSs.
> Im fairly certain everyone who says this has simply forgotten how slow mechanical hard drives were.
Absolutely, but I would go even further with this. I can't prove it, but I would bet a lot of money that Windows 10+ has made using a spinning disk even slower. I would guess optimizations around disk access were entirely different in the XP era compared to now, when it is assumed everyone has an SSD.
Anyway, I had an old laptop that ran like absolutely dog shit. I put an SSD into it and it magically became usable again.
More accurately:
+ "portable" (single exe with no automatic unzipping of dlls or anything)
+ commercial and unwilling to redistribute compiled object files (which together with the "portable" requirement, means no LGPL)
+ dark mode
Windows GUI apps is painful. Drop any one of these requirements and there are good established options.
Specifically I think most "portable" applications use win32 because, usually, portable => small, simple application where functionality is more important than dark mode or other styling ability.
> Windows GUI apps is painful. Drop any one of these requirements and there are good established options.
The "portable" one is not a hard requirement. It's a whimsical self-imposed constraint, which makes as much sense as complaining that you can't stand on your right foot on Tuesdays. All installer toolkits released in over two decades support deploying arbitrary components. Is this not a solved problem?
WinUI3 supports dark mode/theming out of the box along with fully customizable styling. It's as free as it gets. It's also Microsoft's official GUI framework for Windows. But the blogger rejects it because... Because what?
Well I remember one project where having the app small and portable or at least self-contained was a hard requirement. It involved an embedded device (ridiculously complex and over-engineered embedded device) that used customized USB flash sticks for user authentication, data transfer and firmware updates and configuration. The partitioning scheme of the update/configuration scheme meant that I had only about 16MB of free space on the windows-visible partition for a Windows GUI configuration application for the thing.
Originally I started writing it in MFC, but MFC is not exactly good match for something so trivial and all the abstractions meant for document-based applications were mostly in the way and I ended up doing it in Lazarus.
And those COM errors that just kill the process, bypassing C++, and .NET exception mechanisms? lovely!
No designer, manualy editing IDL files for XAML C++ bindings, without any kind of syntax highlighting or code completion, manually merging generated C++ code, even more lovely.
Using a Webview wrapping Bing Maps, instead of the native UWP map control, even better.
"Portable" i could see a few use cases. No MSIL and only native code, however...
Anyone can compile a static binary with FLTK and have the binary size start under 100KB.
I've used FLTK for an application. It relies heavily on opaque pointers and convention. The compiler will not help you out if you mess up.
https://github.com/gammasoft71/Examples_FLTK/blob/c6f630eaa3...
You can use dynamic_cast instead of reinterpret_cast. If the pointer isn't correct it would return null. A better solution is to subclass the widget, store a function pointer for the callback which takes the same class instead of an Fl_Widget, and call that in the callback: https://github.com/MoAlyousef/FLMH This uses a std::function for the captures but you can use a function pointer as well.
You can do that with straight win32 as well. Steve Gibson has a bunch of utilities and most of them are pretty tiny. His DNS Benchmark is one of the larger utilities at 169k.
I like win32 and you can get a lot smaller with win32, but there are a lot of things missing. FLTK has a lot of components, component layouts, fonts, file system stuff, networking, audio, an openGL context, image loading and it's cross platform.
I'm confused. What is "missing" from Win32? To be clear, I count all base DLLs included with Windows a "Win32". One thing I can think of from your list: component layouts. Resizable windows with component layout is awful in Win32.
Or with Lazarus, I've tested it a year or so back. Under 50KB, IIRC, for a CLI Hello world app, though, not a GUI one. Similar size with a D app.
nuklear solves all of these for me, plus it's plain C
> Writing the GUI part of the program should not take more time than the actual functionality
I don't understand why this is a rule. I mean, I don't know what the author is trying to build, but in general the GUI is the part that the users spends all of their time interacting with. I don't see why it would be a problem if a little more time was spent there.
I agree.
Also, in my experience, writing UI code is usually more(!) work than writing the functionality underneath, because
a) styling / layouting has to be learnt from scratch (e.g. because of a proprietary language, e.g. QML or QWidgets for Qt)
b) you have to take care of every frikkin' single user interaction (which becomes worse the more dynamic and custom your UI is), and building proper accessibility is also no walk in the park
It's a real engineer's way of looking at UI, as a necessary evil to have the user use the "real" part of the software
I had a similar struggle. I needed a truly cross-platform (Windows, Linux/Wayland, Mac, iOS, Android) GUI toolkit with rich controls library and reasonable theming. In fact, the only good option is QT and it's very hard to be productive with C++, it still lacks even basic features, like type deconstruction and ADTs/GADTs with exhaustiveness checks. QT bindings for other languages aren't mature enough.
Apart from QT, there is Avalonia, which is full of bugs. Linux support is remarkably bad.
Also there is Kotlin/Compose Multiplatform. It lacks good documentation, advanced controls and still full of bugs.
I was unable to find any good controls library for JS/TS, even paid ones (like Telerik and others) are pretty messy. So, Electron, Capacitor, React Native - they all assume a non-trivial effort to be put into even a very basic app.
Flutter feels extremely immature, and the strange popularity of global singletons makes it extremely hard to navigate even small codebases.
Are there serious issues with wxwidgets? When I was looking for this sort of things it was unglamorous, but had decent bindings with several languages and looked decent enough. I agree with your assessment of the other alternatives.
If I go with C++, I'll take QT, which has lot more extensive controls library and in fact allows me to be more productive than wxw.
Unfortunately, the main productivity limiter is C++ and that's something I really want to avoid. I've been writing C++ professionally for about 8 years so I think I can make such statements.
After doing a "Hello World" window for every feasible GUI toolkit I'm starting to think I should be looking for reasons I can't just use Godot.
Electron = nontrivial effort? What is so hard about Electron? The boilerplate is a snap, compared to Qt/Win32 boilerplate. Where do you fall down?
You need something else to run your electron app on mobiles. Ok, you take Capacitor, fine. Probably you'll take React (or something else) to manage your state. Great. You still need some UI toolkit. Literally all of them, even the paid ones, are pretty basic and dumb. So, most likely you'll have to make your UIs pretty basic and dumb, or reinvent the world and/or dig through tons of half-baked libraries which deprecate faster than you manage to integrate them.
Modern QT (with QML) has very low amount of the boilerplate, all the 7guis examples can be implemented with 20-80 LoCs and will run on all the platforms, although despite all the modernization efforts, C++ still feels dated and it's nearly impossible to be productive with it. The main issues are: lack of pattern-matching with type deconstruction, lack of ADTs/GADTs, lack of closed hierarchies, lack of exhaustiveness checks, lack of closed type hierarchy (no top/bottom), lack of typeclasses, lack of first-class functions (yes, while there is some syntactic sugar, it's just a sugar, e.g. you can't return two different lambdas depending on the template parameter from one template function).
I'm teaching myself the Win32 API for a future RE project, thinking that knowing it helps with the reverse engineering effort. I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet.
It actually take s a lot of work. The boilerplate code is OK but I never realized that showing strings on Windows is such a PIA. I have deep respect for anyone who wrote Windows GUI apps back in the late 80s -> early 90s before RAD is a thing.
As a side note. I recently got a book about WinG game programming on Windows 3.X/95. I remember back in the day the game Fury3, a fascinating 3d flight shooter game, was developed in WinG. It could be an interesting archeology project to develop something serious with WinG, the predecessor of DirectX.
I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet.
You could just use the standard Edit control for that. If you really want to do it manually, which I have done, it's less than ~300 lines of code for the whole app (including working scrollbars). The binary is less than 4k.
but I never realized that showing strings on Windows is such a PIA.
Are ExtTextOut and related functions all that hard to use? How much simpler do you think it could be?
Thanks, I don't know about that yet, so it's going to be while.
For the string it's mostly the wchar and char stuffs. I think I'm getting a hang of it.
IIRC WinG was basically a way to set up a GDI device context that corresponded to a frame buffer, so you could take your DOS SuperVGA code and run it under Windows, only redoing sound and input. It's been almost 30 years though. :)
That's what it was, mostly.
You could do pretty decent games using GDI as long as you just wanted to blit some sprites and were very much adhering to what GDI would give you. If I remember correctly, all the examples in the "GameSDK sampler CD-ROM" (the original name of DirectX 1.0) were in fact not done with GameSDK or even with WinG, but straight GDI.
I think it was better and easier to set up a DIB, treat it as a double buffer of sorts and only use GDI to BitBlt it to screen.
Don't ask me how you do that, though it probably would not take me too much to page that stuff back into my brain by looking at the Microsoft Win32 manuals. Maybe CreateDIBSection? I still remember my kernel32.dll, but not GDI or User.
Anyway, what WinG did (and all it did) was speeding up the blitting part.
I don't know much about the performance, but I guess non-action games should be fine?
The GameSDK samples included scrolling backgrounds and that kind of stuff.
Yeah that's probably what it was back in the day. I recalled games run pretty slowly on Windows before WinG came out. Fury3 looked pretty slick, even in today.
> I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet.
> It actually take s a lot of work. The boilerplate code is OK but I never realized that showing strings on Windows is such a PIA. I have deep respect for anyone who wrote Windows GUI apps back in the late 80s -> early 90s before RAD is a thing.
The late 90s experience with VBA and the Visual Studio designer is, on the other hand, really good. As was the proprietary Borland Delphi experience.
You could do worse than try building an MFC app in VS to get something working and then reverse engineer the details out of that. Strings are not a pain provided you remember -DUNICODE and use wchar for everything (and the related functions).
I'm amazed Fury3 worked under WinG. I used WinG for some simple 2D games, but I don't think I would have tried texture-mapped 3D!
We wrote this game on DirectX 1.0. It was a pig because the game was designed to be all 2D sprites, but early in the project it became clear there wasn't enough RAM, so I wrote a 3D engine that integrated with the 2D backgrounds. The video cards of the day didn't like that shit, and there was no acceleration at the time.
https://www.youtube.com/watch?v=9UOYps_3eM0
All the DirectX code itself felt sluggish as games were coming from highly optimized bare-metal C/x86 to running on a multi-tasking OS through an API that was written in (probably) pretty unoptimized C++.
Wow that looks pretty slick. Now I know why early Windows don't have competitive games and why things like WinG and DirectX are pretty big. I think Carmack did not jump on the DirectX wagon until much later.
Yes, he and Id pushing miniGL are pretty much why Glide lost and everyone was into MS-DOS and OpenGL graphics for a while.
However by DirectX 10, he was also not happy with OpenGL mess, and changed his mind on DirectX.
https://www.bit-tech.net/news/gaming/pc/carmack-directx-bett...
Check out the Scrollbars series from Raymond Chen:
https://devblogs.microsoft.com/oldnewthing/20030731-00/?p=43...
https://github.com/mity/old-new-win32api?tab=readme-ov-file#...
That book is worth gold from Windows game development archeology point of view, it is quite hard to find anything related to WinG online.
It's called "Dungeons of Discovery". The book includes a CD with resources to build a mini yet full blobber game. The CD also contains WinG.dll conveniently.
Apple and Microsoft underinvest in their widget toolkits. It’s especially damning for Apple since they spend the money to write numerous custom widgets (e.g., the widgets in their professional apps like Final Cut Pro and Logic Pro) but don’t upstream. Nobody is inspired by yet another implementation of button or tab widgets.
No idea about Apple, but I'd strongly disagree for Microsoft. In one way of speaking, they invest too much. WinUI3, like the article mentions has such a sordid history. It started as WPF, and WPF was (is) awesome. It's simple, clean, runs on a bunch of different platforms, doesn't have a zillion dependencies, has a great community, and is just all around pleasant to work with.
So naturally Microsoft decided to completely scrap it, replace it with a far less functioning successor, flop, and then repeat this process over and over til we get where we are today after WPF->UWP->WinUI2->WinUI3. And WinUI3 has also already been completely abandoned. Contrary to this article, it still doesn't even have a visual designer. The amount of time, energy, and money Microsoft has spent with all of these successors is going to be remarkable, just to keep throwing everything away and restarting.
Oh and while all of this was happening they've also been developing Xamarin, MAUI, and more that also all do pretty much the same thing - in completely incompatible ways, with a similar general trend of having the attention span, focus, and overall quality of a 13 year old ADHD boy, in a Japanese arcade, after 7 shots of espresso. This just isn't the sort of thing you could do without just completely absurd budgets and minimal concern about actually making something great. If they had instead just stuck to perpetually refining WPF, UI development on Windows would be a utopia today, and they probably would have saved an immense amount of money, or at least manhours.
A lot of the best people left MS. People forget that MS was so completely dominant that it attracted a lot of talented people who wanted to do big things. Since then the competition from the FANG companies have brain drained them, not helped by MS insistence on paying less than their peers, sure there is no state income tax but the company shouldn’t be trying to capture all of that difference.
The net effect is that not only are they not capable of building things as well as they used to, they can’t even maintain what they already have. And how would anyone go about fixing such a culture. I think that’s a big part of why MS has been so generous to OpenAI while also keeping them at arms length.
Inertia is incredibly powerful and big companies can remain successful for long after their technical competence dissipates.
Also, iirc there is no Windows department anymore at MS. Hard to make a great platform in these conditions.
> And WinUI3 has also already been completely abandoned.
I'm not sure where you got that impression, but WinUI3 is in almost all of Microsoft's software at this point. Admittedly a huge amount of it is embedded inside React Native, but WinUI3 seems to be the UI toolkit that has won and is still going strong. They announced a bunch of WinUI3 enhancements at BUILD even.
(One such announcement is a coming standard control for the sort of custom Windows Title Bar with a search box and branded logo and extra buttons that has become common in every first-party application from the Microsoft Store app to all of Office and many other places.)
> Contrary to this article, it still doesn't even have a visual designer.
Huh? Visual Studio has a visual designer for the WinUI 3 flavor of XAML. If you don't want to write XAML to back your UI they probably will never support a Visual Designer for you (ie, C# UI seems neat and maybe a bit more "functional programming", but I'd rather use XAML just to have the Visual Designer at least). Last I checked the XAML designer works just fine even in C++ projects targeting WinUI 3.
Visual Studio's designer really does not support WinUI 3. Try it! Hot reload also doesn't work worth anything. There's an ongoing issue/discussion on Github here [1] from 2021. There's also loads of fundamental issues like various controls causing replicable crashes with drag and drop, the community calls are disappearing, and more.
[1] - https://github.com/microsoft/microsoft-ui-xaml/issues/5917
Sure, it is definitely very buggy, but the point is that it still exists and is useful to some extent. I was refuting the claim that there is *no* visual editor, not the claim that the visual editor we do have is maybe deficient and buggy.
Relatedly, I still think it is something of a shame that (Expression) Blend didn't survive to the modern era. A designer-focused XAML design tool that doesn't need a full Visual Studio install (nor the same sort of expensive VS license) and feels more like Firefly or Figma or whatever other designer-focused tool is current en vogue would be really handy in a lot of situations.
I don't think it is the only reason that designers tend to prefer HTML (and thus we use Electron or similar to placate the designers that think that "just copy and paste it from the design tool" works "well") over XAML, but it certainly doesn't help that there isn't a "XAML Figma" and it's a shame on multiple levels that Microsoft recognized that threat early on, built a solution, then got confused why they built it, confusingly merged it into Visual Studio licenses and installs, which lead to its sadly inevitable death just a few years before it would have been very helpful to have to send to some designers and stop getting HTML-only mockups.
To be clear I am saying that drag and drop operations do not work during runtime. The designer literally does not work at all, for WinUI 3, for reasons that are not at all clear, since Visual Studio had a 'native' designer for WinUI 2, as well as the weird disconnect with Blend as you mentioned.
I almost feel like you're mixing up WinUI 2 and 3, because the designer was kind of borky for WinUI 2 but did work, and was overall an okayish experience. But for WinUI 3 it's an entirely different game. Early on the messaging was that the designer would be "coming soon" (tm) and that people could just use hot reload in the interim, then at some point hot reload ended up completely broken as well, Microsoft gradually started withdrawing engagement with the community, and here I am saying it's been defacto abandoned.
The point of the designer is not just mock ups. At many (most?) small businesses and studios the developer/designer dichotomy doesn't exist. There's a reason lots of companies are still even using e.g. Winforms. A high functioning designer simply dramatically improves both productivity and quality.
While Apple could stand to improve some aspects of their UI toolkits (and you're right that private widgets have long been a frustration), I'd say they're in an entirely different plane in existence relative to Microsoft in this regard.
The most solid of their toolkits is far and away UIKit on iOS. It's got almost all of the best parts of AppKit with over a decade of thoughtful tweaks, polish, and QoL improvements. AppKit has become a bit more neglected since iOS stole the title of favorite child from macOS but is still quite solid. Both have an extensive set of highly capable stock widgets and with both, you can write just about anything imaginable pretty easily without importing a single third-party library. Neither locks you into a WYSIWYG editor or hand-editing XML and are pure-code-friendly, particularly since the addition of autolayout anchors.
SwiftUI is finally getting to the point where it's not so green and is becoming a more practical choice. Though it wasn't a headliner, this recent WWDC brought a number of long called-for improvements.
By contrast, WinUI lacks such fundamental basics as a tableview/datagrid, meaning you're going to be rolling your own or importing third-party widgets much more frequently. While you're not as locked into XML layouts and resources as one would be with Android Framework with it, it's not as friendly to pure code. It's also decidedly mobile-esque relative to AppKit (likely owing to its UWP heritage) which might be a problem if the goal is to build a true desktop-class app.
UIKit is actually nearly 20 years old and AppKit is getting close to 40…
I'm not sure what point you're trying to make.
> uses native Win32 components and offers no styling options
It's a feature.
Custom styling should be considered a hostile pattern in most cases, except in highly specialized software with workflows dependent on prior user experience, such as DAWs.
Yes full agreement from me.
I think loads of energy is wasted in development because someone wants custom stuff like buttons or input boxes without real reason where off the shelf GUI would work and would be much cheaper.
> Custom styling should be considered a hostile pattern in most cases
Why? Almost every website has custom styling and yet it doesn't seem to inhibit users from using them.
Good UI/UX patterns seems to be universal. As consistency is part of good UI/UX there are things that should be consistent with the underlying platform. But consistency with the platform is not equally important for all things. For some things, like window management, it's much more crucial, that it is for other things, like roundness of buttons.
> except in highly specialized software with workflows dependent on prior user experience, such as DAWs
It's not just about prior user experience. If a custom control enhances UX for a specialized task, it has a good reason to break some of the consistency. All specialized software (DAWs, graphics applications, IDEs etc.) have such features. Limiting themselves to just native components would lead to a suboptimal user experience.
How would you know inconsistency among websites isn't inhibiting users from using them? There's not a Web A and Web B to do A/B testing on.
Roundness of buttons? Buttons shouldn't be round in the first place. Back in the day, they were these rectangular things with a shadow and a highlight. You could instantly things you can and cannot click on. Now, it's anyone's guess. Do people click on the wrong stuff? Do people fail to discover functionality because it's hidden in plain sight? Of course they do!
Is there a place for custom components, yes, but not to the extent that every website out there is styling their buttons, and that even Windows itself is hiding scroll bars.
> Buttons shouldn't be round in the first place. Back in the day, they were these rectangular things with a shadow and a highlight
I dunno, looks round enough to me https://upload.wikimedia.org/wikipedia/vi/4/4e/Windows1.0.pn...
There's a lot of A/B testing going on on the web.
> Buttons shouldn't be round in the first place.
Is there any data available to back this up?
Modern UIs are not perfect by any means, but from what I remember, those old UIs were not great either... even worse in terms of UX on average.
While consistency is important, placing it above all else, leads to suboptimal UX and bland UIs. How many times did you hear people raving about how great is the UI of an app build with a generic form builder?
What about a simple dark mode, that even the OS provides options for?
> It would require me to write a custom paint function for every single control, which would take so much time I could raise a family in the meantime
This is a weird comment that shows the philosophy of old school win32 has not clicked for them. The key element in win32 is the wndproc. Most controls ask their parent what color they should be via a window message.
If you find this inconvenient, wrapping that in a small library to remove boiler plate is not a big deal.
> Most controls ask their parent what color they should be via a window message.
There are a LARGE number of areas where this is not provided, such as the text color of a disabled control or the checkbox area of a checkbox control. Even for the cases where such customization points were provided, many of them were broken when theming was added in Windows XP and in comctl32.dll version 6 in Vista, which ignores some of them in favor of theme colors or images. Menu colors, for example, are ignored when theming is enabled.
The result is that if you want something approaching a reasonable dark theme with Win32 stock controls, you will often need to resort to full owner-drawing of the controls. This is not a minor task.
Do you happen to have links to any good documentation/articles on this topic? I'm working on what amounts to a dark theme for Win32 controls and largely making it up as I go along, relying on tidbits and off-hand mentions from defunct blogs.
Check out my win32 dark mode menu bar in case it comes in handy.
Also I know far far too much about the internals of classic win32 rendering if you have questions
https://github.com/adzm/win32-custom-menubar-aero-theme
I have a reasonably complete implementation of dark mode in my open source application, Explorer++. It uses the standard Win32 controls and applies a variety of strategies to get something that looks more-or-less cohesive when dark mode is enabled. ThemeManager.cpp[0] contains the bulk of the functionality. It could be useful as a reference for how you might create a dark version of a standard Win32 control.
[0] https://github.com/derceg/explorerplusplus/blob/4bad3ab95d87...
Afraid not, had to piece together a lot of it myself. There are lots of examples available for various components of varying quality -- you'll find some code examples that don't work well with high DPI or all of the sub-modes of a control.
Some controls like buttons, list boxes, list views are reasonably well behaved, especially when theming is turned off. Combo boxes and toolbars are more temperamental. Check boxes, scroll bars, menus, and message boxes require a lot of custom painting work.
Would you mind sending me an email (address in profile)? I'd love to pick your brain about some of the trickier ones I'm running into.
Writing GUI apps is painful everywhere, and has been for years.
I remember the half-baked transition from Windows Forms to WPF, which was then taken-over by the Windows Phone initiative, which was also extremely painful and half-baked.
There's a reason electron is so popular, despite all the complaints about it as a platform. Don't blame the electron devs, blame Microsoft for completely failing to support their own platform. That lack of long-term support and consistency extends to a ton of areas in the Windows world, not just GUI development.
The lack of windows support for windows GUI's on windows is mind blowing. I remember absolutely whipping up Visual Basic line of business apps using the form designer in Visual Studio and data bound controls etc. If you wanted more there was MFC (with MTL developed by some insiders I guess at microsoft)
The absolute insanity of going to WPF (wasn't data binding via reflection -> these apps got horribly sluggish!) then to UWP (monster controls for touch I guess?) is honestly mind blowing. The emphasis on Universal Windows Platform as "the future" of app development is absurd. Every time the design language behind this infects another settings app in windows we LOSE functionality! Can you even have more than one settings window open anymore with the new and improved UWP?
Then there is WinUI? Then there is MAUI? THen there is blazor on the desktop?
Has Microsoft confused you yet? They've confused me. Each of these introduced as the best thing since sliced bread, and back with tooling with broken forms designers and more.
> The emphasis on Universal Windows Platform as "the future" of app development is absurd.
Remember when Microsoft honestly thought they had a shot at making a mobile platform to compete with Android and Apple?
Say what you will about their chances of succeeding, but the Windows phone is the best phone I ever owned
The problem with all of these technologies is that they were invented by different divisions of Microsoft to do different things. That, and Microsoft chasing the Next Big Thing.
What we consider to be "Win32 apps" are built with a framework in USER.dll, which is half reimplementation of the classic MacOS Toolbox API and half a pure-C object oriented class system. It's been here since the beginning, and is the lowest common denominator for getting anything on screen. Every other toolkit eventually opens a USER window, attaches the appropriate window class and wndprocs to it, and then yields CPU control to an event loop that, among other things, contains a Windows USER message pump.
USER, being an object-oriented, pure-C[0] API, is infamously verbose to work with. The "200 line Hello World" example everyone passed around back in the 90s is specifically that verbose because of all the bookkeeping you have to do for USER's sake. It is possible to build USER apps that work well, but it puts a lot of onus on the programmer. Even things like high-DPI support[1] or resizable windows are a pain in the ass because they all have to be implemented manually.
Microsoft's original answer for "USER is too hard" was to adopt Visual Basic or MFC as you mentioned. AFAIK .NET WinForms was also a wrapper around USER. This is why Windows had a cohesive visual appearance all the way through to Windows 7, because everything was just developer-friendly wrappers around common controls. Even third-party widget toolkits could incorporate those controls as subwindows as needed[2].
The problem with USER is that it was built for multiple windows and applications that render (using the CPU!) to a shared surface representing the final visible image. Modern toolkits instead have multiple separate surfaces and draw on them as needed before presenting a final image to a compositor that then mixes other windows together to get a final image. Windows Vista onward has the compositor, but the UI toolkits also need to be surface-aware instead of chucking a bunch of subwindows at DWM at the last minute.
WPF is the first attempt at a modern UI toolkit. Relative to USER resources are replaced with XAML and window classes replaced with... well, actual language classes. Except it was developed by the DevTools division (aka DevDiv), and only ran on .NET with managed code. If you had a native application or just didn't want to pay the cost of having a CLR VM, tough.
Then the iPhone launched. And the iPad launched. The thing is, good tablet UI needs GPU-acceleration up and down the stack, so Microsoft shat themselves, gave the Windows division (aka WinDiv) the keys to the castle, and they completely rewrote WPF in C++ with some fancy language projections. That became "Metro" in Windows 8, then "Modern UI" after a trademark dispute. Microsoft wanted Windows 8 to be a tablet OS, damn it, with full-screen only apps and no third-party app distribution.
And then most people just bought Surface tablets, opened the Desktop "app", and used the same USER apps they were used to, complaining about the Start Screen along the way. So Microsoft pivoted back to a normal desktop with Modern UI apps, which are now called UWP apps, and there's a whole bunch of new glue APIs to let you stick XAML subwindows inside of USER or just use UWP outside of AppX packages, which is what Windows 8 should have done, and now everything is just a mess. WinUI 3 is just an upgrade to the XAML library that UWP apps use, but it sounds like Yet Another Toolkit. MAUI is some kind of meta-toolkit like the old AWT on Java.
At some level, I can explain this, but it's not reasonable. There is no "native" UI toolkit or consistent look-and-feel on Windows anymore. I suspect this, more than anything else, is the reason why Windows killed Aero blur-behind everywhere, and why Electron apps are so damned popular now. HTML and CSS are almost as old as USER, but with consistent engineering support and developer experience.
USER is an enhanced clone of the MacOS API, so it's natural to see what Apple did when confronted with the same problems. MacOS didn't have an object system at all, you just threw a bunch of controls onto a list and the system rendered them. That (along with user mode applications) was actually one of the reasons why they bought NeXT. OSX's AppKit toolkit shipped with compatibility bridges for Toolbox apps, but it was still about as advanced as USER was when it came to GPU usage, given that it was built around the same era as Windows, just for beefier hardware.
So what did Apple do? They made AppKit speak layers. They wrote a whole new compositing system called CoreAnimation to do in-process compositing, with all the common controls knowing how to manage it and layer-unaware third-party controls just doing whatever made sense. And this itself was a trojan horse for UIKit: the compositing library had been written to support a touch tablet demo that was later rolled into the Purple project to produce the iPhone. Y'know, the thing that actually kicked Microsoft's ass so much they decided to fracture their development ecosystem into 40 different UI toolkits with confusing names. In comparison, on modern macOS the big split comes from SwiftUI and Catalyst, but those are both wrappers around AppKit controls rather than ground-up rewrites of UI toolkits nobody dares touch.
[0] Or possibly Pascal, given the MacOS heritage
[1] The correct way to do high-DPI is for the windowing toolkit to work exclusively in virtual coordinates. Physical device coordinates and their derivatives should be converted away from at the earliest possible convenience and converted back into as late as possible. At a minimum, no user-facing APIs should use physical coordinates.
USER does not do this, even though there's an option to make it do this, which has worked wonders on every non-DPI-aware app I've thrown at it.
[2] Or, alternatively, implement their own. My favorite story about this is Internet Explorer, which ships with it's own implementations of common controls specifically just so that HTML form elements don't have to hold an HWND each and can share the parent window.
The mess this made showed up everywhere.
AppX packages got a bad rep as well for a couple of reasons. Lots of new footguns when dealing with them or trying to remove them for imaging / mass deployment scenarios.
The first introduction to AppX was often a metric load of crap on the machine - see below for a sample of the type of AppX stuff that was the first introduction to AppX for some folks which were often low effort marketing type stuff.
Get Skype: Get-AppxPackage -allusers skypeapp | Remove-AppxPackage Get-AppxPackage -allusers zunemusic | Remove-AppxPackage Get-AppxPackage -allusers maps | Remove-AppxPackage Get-AppxPackage -allusers solitairecollection | Remove-AppxPackage Get-AppxPackage -allusers bingfinance | Remove-AppxPackage Get-AppxPackage -allusers zunevideo | Remove-AppxPackage Get-AppxPackage -allusers bingnews | Remove-AppxPackage Get-AppxPackage -allusers people | Remove-AppxPackage Get-AppxPackage -allusers windowsphone | Remove-AppxPackage Get-AppxPackage -allusers bingsports | Remove-AppxPackage Get-AppxPackage -allusers messaging | Remove-AppxPackage Get-AppxPackage -allusers connect | Remove-AppxPackage Get-AppxPackage -allusers contactsupport | Remove-AppxPackage Get-AppxPackage -allusers feedbackhub | Remove-AppxPackage etc...
> Writing GUI apps is painful everywhere, and has been for years.
Disagree. GUI development on Apple platforms using either UIKit or Appkit is something I've always found expressive, simple, and fun. SwiftUI is a different beast, but to say it's painful everywhere is not accurate.
Windows Forms (C#) is basically a continuation of Visual Basic, it's not very painful at all. The only painful bits are when you need to lock a bitmap and deal with raw pointers, and you need to use the "unsafe" keyword.
To me, Windows Forms is where MS should have stayed. I don't want XAML to compile to C# code, and I don't want to be forced into using their MVVM system. I just want to be able to put boxes on the screen and fill them with text, then handle user interactions with callbacks. Basically, vanilla javascript but in C#
Flutter is actually quite nice and works well on desktop too. If Google continues to develop it I could see it becoming the first choice for a lot of developers.
> Writing GUI apps is painful everywhere, and has been for years.
I think UIKit and SwiftUI (and to a lesser extent Appkit) are great
Oddly AppKit seems to be one of the most stable desktop frameworks I have worked with. They've made breaking changes, sure, but they haven't been rewriting, and rewriting, and rewriting the same stuff for the last decade and a half.
The situation on Windows these days feels like... cognitive dissonance. If given a Windows app assignment today, I'd pick WinForms if less complicated, WPF if a larger project.
AppKit is very stable yes but it shows its age a little more than UIKit. As you say still better than anything Microsoft can offer
For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more.
If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your C++ DLL with static C runtime, your C++ DLL won’t have any dependencies apart from OS components like kernel32.dll.
If you insist on having a single EXE you’ll need to bundle it and extract, but the additional code for the P/Invoke to work is like 4 lines of that code, call LoadLibraryW from kernel32.dll early on startup, before using any stuff with [DllImport] from that DLL.
I do not recommend C++ CLI. Write normal C++ which compiles into native code without any weird metadata. You can use C APIs, or COM interop with ATL, or check this library of mine https://github.com/Const-me/ComLightInterop/
If you start with this approach (as opposed to refactoring a C++ app you already have) you’ll find out that you need substantially less C++ than you expected. Essentially, C++ is only required for 2 things: CPU-bound number crunching, and code which consumes large C or C++ libraries (Windows SDK is huge and pieces like D3D or MediaFoundation require C++). It’s much easier to do everything else in C#, as the language and especially the standard library are just better.
I do not recommend C++ CLI.
Can you elaborate on why?
I looked at various ways for interop between C# and C++ over the years, and overall found C++/CLI to be the best overall for our particular application types: it's a separate layer bewteen a C++ backend (which is also used in other non-gui applications), with a windows-only WPF desktop application on top. Mainly because the C++/CLI code itself is simple, readable and fairly effortless to write and maintain. A bit repetitive at times though, but that's going to be the case for any such layer AFAIK. Integration on the C# is seamless, with code completion etc, and C# interfaces can be implemented in C++/CLI directly for instance. The initial setup takes some work but with conversion between common types implemented (ability to e.g. IEnumerable<ManagedT> <-> std::vector<NativeT> or std::iterator<NativeT> etc) it's all pleasant and good.
or check this library of mine https://github.com/Const-me/ComLightInterop/
Gotta say this looks neat, but it's exactly the type of code I'd rather not write: UUIDs, bunch of macros, unclear mapping between return types (HRESULT vs bool), having to declare same interfaces both in C++ and C#, ...
> Can you elaborate on why?
The language is only supported in a single compiler, and is specific to Windows.
The language is based on both C++ and .NET runtimes, and when I used it (admittedly, it was many years ago) I didn’t like the usability consequences. These two runtimes interact in a weird way. It’s hard to compose data structures which contain both managed and unmanaged pieces, see that question https://stackoverflow.com/q/10523268/126995 You can’t include Windows SDK headers in CLI code, not gonna compile: https://stackoverflow.com/q/26502283/126995 Same applies to most third-party C and C++ libraries.
So with CLI you have 3 languages instead of just two: C#, C++/CLI, and classic C++.
> it's exactly the type of code I'd rather not write
I have used that library in multiple projects in the last 5 years, for Windows and Linux platforms including ARM Linux, both open source and commercial. It worked great for my use cases.
Here’s an open-source example of a relatively complicated COM interface implemented on top of ComLightInterop. C# interface: https://github.com/Const-me/Cgml/blob/master/CGML/CgmlNet/iC... C++ interface: https://github.com/Const-me/Cgml/blob/master/CGML/Cgml/API/i... C++ implementation: https://github.com/Const-me/Cgml/blob/master/CGML/Cgml/D3D/C...
As you see it has very few macros, no bool returning methods, very clean API between managed and unmanaged parts, and most importantly very readable idiomatic codes on both sides of the interop.
I’d like to add that if you make mistakes when writing these C++ and C# projection of a COM interface you’ll find very soon because it’s likely to crash on first use due to /GS compiler switch. Also trivial to debug and fix because VS supports mixed-mode debugging.
I have been trying to learn WPF for a long time, but have drifted into web apps.
Can you point me to any good resources to be able to make complex multi window apps in it?
I have good experience in Windoes forms and am well versed in c# and dotnet.
I’ve learned WPF long ago, and I no longer remember how specifically I did that. Still, that introduction seems pretty good at the first sight: https://wpf-tutorial.com/
Learning is easy, it’s very user friendly and IDE support is great. Mastering the framework for complicated GUI is harder. Here’s a few tips.
Treat XAML the same way as any other source code. Keep it human readable: write comments (the syntax is the same as in XML i.e. <!-- A comment --> ), and use proper indentation (I often use tab size = 2 for XAML files). When a particular window or control grows too huge, consider moving large pieces into separate XAML files with a user control or maybe a resource dictionary.
MVVM design pattern is great, use it whenever possible. Don’t forget to implement INotifyPropertyChanged and/or use ObservableCollection<T> for dynamic things. Having said that, I tend to avoid opinionated MVVM frameworks like Caliburn.Micro, IMO these things sacrifice simplicity for testability.
Sometimes for complicated UX use cases like drag/drop or mouse painting handling these input events in code behind is way simpler than trying to stick with MVVM. Luckily these approaches compose rather well; it’s possible to use MVVM for most of the UX and code behind logic only in the few places where it simplifies things.
Similarly, for diagrams or similar GUI you can directly create and manipulate these UI elements with C#, placing then on a canvas. Technically possible to do in MVVM-y way e.g. an ItemControl with a Canvas in the ItemsPanel, just much harder to do especially the layout on resize. BTW, you can define styles for these elements in XAML markup, no need to set up every possible font/brush in C#.
Couple advanced features I often use are IValueConverter interface to translate values or types between views and view models, and DataTemplateSelector to programmatically switch between multiple data templates.
I tend to avoid DataTrigger in XAML, I prefer exposing additional public properties from my view models.
Thank you for your patient and detailed response.
I liked this Pluralsight WPF course a lot, the instructor (Thomas Claudius Huber) is clear in his explanations and seems to be very knowledgeable.
https://www.pluralsight.com/courses/wpf-6-fundamentals
WPF has been superseded (supposedly) by UWP / WinGUI / MAUI / Blazor?
WPF seems to be one of the preferred native UI platforms:
"Microsoft will refresh WPF with new Windows 11 theming and hyphen-based ligatures support for Microsoft .NET 9 and will continue to invest in WPF as one of the two preferred native user interface platforms on Windows."
The other preferred native UI platform seems to be WinUI 3: "WinUI 3 joins Windows Presentation Foundation (WPF) as the two recommended native UI platforms for developers."
https://news.microsoft.com/build-2024-book-of-news/
I don't know about MAUI / Blazor.
Nope, the GUI story is so bad, that at BUILD 2024, WPF was made again an official Windows GUI framework for .NET devs, see BUILD 2024 sessions regarding Windows programming.
Haha.. That is too funny - I haven't been following this closely anymore. It's honestly wild. Does WPF still do data binding by reflection? I can usually "feel" a WPF app if I'm doing a lot of data work.
I remember when WinForms (which I thought was fine!) was killed. Why they just didn't continue to build on that I don't know (yes, I've heard the explanations, the importance of things like having XML (barf) in the framework).
How can you not be absolutely kicking butt on your own platform with a great story especially because they absolutely HAD a great story both at entry level LOB and advanced LOB.
WinForms is still actively developed (although it wasn't always).
I prefer XML to manually placing controls in a window and clicking around a designer GUI at all times. XML is trivially editable by hand, WinForms auto-generated C# isn't.
Supposedly is being worked on for making it more Native AOT friendly.
How we got into this mess? WinDev and DevDiv politcs.
After the Longhorn debacle, its technologies landed on DevDiv, like WCF and WPF.
Sinofsky and friends never were that keen in having .NET coming into their turf, it is no surprise that Hilo sample for Windows 7, then praises COM and C++ for Windows applications[0][1].
Then coming in this path, WinRT came to be, with roots as how .NET was being designed, before Microsoft decided to pivot it as another Java like technology[2].
A bunch of folks in WinDev, weren't happy with C++/CX, so they united to replace it with C++/WinRT, because extensions, when clang and GCC are full of extensions, promised to give back a C++/CX like developer experience in 2017[3], never delivered, went to have fun with Rust/WinRT.
Now C++/WinRT is in maintenance mode[4], and Rust/WinRT never took off, and is now Rust/windows-rs[5].
As paying customer, impacted by those childish attitudes, I would have had the whole team fired.
Finally, check the amount of bugs and complaints on their respective repos,
https://github.com/microsoft/microsoft-ui-xaml https://github.com/microsoft/WindowsAppSDK https://github.com/microsoft/cppwinrt/
And then compare with Project Reunion vision from 2021, and where we are three years later
https://blogs.windows.com/windowsdeveloper/2021/03/29/announ...
Mainly because along the way, as if those changes weren't enough, they also decided to reboot their initial approach with Project Reunion, WinAppSDK took another route, and here we are.
This is only a short overview of how WinRT went down since Windows 8, thus only those that never advocated for it, can honestly suggest WinUI, as they lack the background of how chaotic it all is.
[0] - https://devblogs.microsoft.com/cppblog/announcing-hilo/ [1] - https://learn.microsoft.com/en-us/previous-versions/msdn10/f... [2] - https://arstechnica.com/features/2012/10/windows-8-and-winrt... [3] - https://www.youtube.com/watch?v=7TdpWB_vRZM&t=2983s [4] - https://github.com/microsoft/cppwinrt/issues/1289#issuecomme... [5] - https://github.com/microsoft/windows-rs
This at least explains what from the outside looks like total insanity.
What's been confusing is they've been chasing all sorts of things (phones / tablets / web development) so clearly had money to burn, but couldn't deliver a basic solution for their own platform.
Clean simple line of business apps (ie, datagrid / listviews needs to work etc with bigger excel type datasets) + maybe RemoteApps or some other remoting option for SAAS type deployment would have been a nice option to have for plenty of folks.
For a lot of use cases the modern solutions are both worse to develop for AND are slower / buggier - so you get little for the effort
UWP was designed primarily for Windows phones, usability on desktops suffers. And it requires windows store, you can’t just ship an installer .exe
WinUI seems to be copy-pasted from UWP, same usability issues on desktops. Unlike UWP, it’s a mess in terms of software quality. Also the runtime is huge, I think the size in MB even exceeds Electron.
About MAUI, it seems Microsoft decided to make an abstraction over native controls. It’s been tried for decades and it always results in the same suboptimal result because these GUI frameworks implement the least common denominator of available UX. In addition to that, on Windows that thing uses WinUI3 backend, see the previous paragraph.
I don’t know anything about Blazor, but it seems that thing is for web apps?
MAUI is basically Xamarin.Forms, rebranded and rewritten, thus forcing the whole Xamarin community to rewrite their stuff, or go elsewhere.
Miguel de Icaza is pretty sour on this, and quite likely one of the reasons he is now fully into Apple ecosystem and Swift.
Blazor started with being only a WebAssembly based framework, then they decided to put everthing on ASP.NET under Blazor umbrella, and are now pushing Blazor into everything that has a Webview, including the stupid idea of Hybrid Blazor in MAUI, basically Electron in .NET.
Blazor is interesting. They are biting off an absolutely metric done of stuff. I will say their development style -> social media etc seems good which might help drive some buyin. They have public roadmaps. The outcomes still pretty rough ("Could not reconnect to the server") when falling off the happy path. So it still had a bit of that "in theory" development style that in terms of use annoys developers.
Just use WinUI 3. Opting into MSIX packaging no longer requires an App Container sandbox.
More info here: https://learn.microsoft.com/en-us/windows/msix/desktop/deskt...
Full disclosure: I work at Microsoft.
WinUI 3 XAML C++ is a joke, versus the old C++/CX tooling in Visual Studio.
Editing IDL files without any kind of Visual Studio tooling, manually merging generated C++ code, no designer.
runFullTrust apps are still subject to file system and registry redirection as well as various capability checks. Running fully unencumbered requires restricted capabilities that only Microsoft can approve.
you can turn some of that crap off: https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/ua...
Note the warning on the page.
> This element requires the unvirtualizedResources restricted capability.
And if you click through the restricted capability link:
> If your app declares any restricted capabilities, then you must provide info during the app submission process in order to be approved to publish your app to the Microsoft Store.
You can opt out of those with manifest metadata. Capabilities aren't enforced if you distribute out of the app store.
The OS will enforce them at installation/launch time regardless of distribution method.
Yes but what I mean is you can declare any capabilities you want, nothing prevents you just asking for whatever you need except Store review.
For >1 minute incremental compile times? No thanks.
[flagged]
incremental compiles. Changing a single line should not take over a minute to compile in 2024.
And it's not even a "truly large" project, your patronising tone is wasted.
The complaint is that writing GUI apps is painful not that it's impossible. In particular, when compared to other platforms, windows has had 30 years, several frameworks, market dominance, and they all still end up getting a D- for one reason or another.
Perhaps the one you're replying to doesn't want a "truly large project".
You're being an unnecessary dick.
Long compile times are annoying and affect productivity. Some people are really sensitive to this type of disruption and it gets very difficult to stay in flow when the only thing you can do is sit and stare at a progress bar. This is particularly offensive to C# developers.
Take your elitist attitude and your gigantic C++ monstrosity elsewhere. Tell me you haven't used a modern JIT language without telling me you're a scrub. Jesus.
Ah, yes, I must be a C++ advocate who has never used a “modern JIT language.” I’ve actually been using them since before the term “JIT” was in common use, just like I used C++ before it had templates or exceptions.
Incremental compile time on the order of a minute should not a big deal in a project. How would someone who can’t handle that have fared in our industry 30 years ago? Yes, faster compiles are nice, but they aren’t what will ultimately limit you unless you have an untreated medical condition.
Where's the GUI designer?
Like the author I too did an evaluation of various UI frameworks, though I ended up settling on WTL (Win32 with some ATL). I might switch away from it and make my own Win32 wrapper in time but for now it works well enough and writing custom controls that feel like standard controls is relatively easy. If you handle the drawing correctly it is also one of the fastest and snappiest systems around.
I had the exact same issues with WinUI3, where each time I compiled and wanted to run the application I had to install it into Windows, with its own start menu entry and registry entries and all that stuff. Really inconvenient and not worth it unless you like and desire that "new app" look of the Settings etc.
Qt wasn't too bad but you still had to do a similar install step within CMake to make the necessary Qt DLLs available to your application to run it. It's also not the fastest system around for UI.
Why do you think Qt isn't fast? Qt apps can be VERY fast. My block editor[1], written in Qt C++ and QML is 4x faster than Bike - a native macOS app - that is already very efficient and performant.
[1] https://www.get-plume.com/
I tried to write a windows App recently (maybe to put in the windows store). I gave up when ...
- Tried to wade through the mess of different frameworks. Some are abandoned, they all have different feature sets etc...
- I found that I could not have anything other than FullTrust (all permissions) if my app wanted to use the/live in the system tray.
- You can't set the size of the window to match the content. You can set a size, sort of, but the min is 500x500 AND it will remember what the user's last size was so if they e.g. maximize it will be the next time its opened regardless of the program settings. In order to do this simple thing I would have to write it as a WPF app with a installer (which as of 2023 can go on the Windows Store)
> Writing the GUI part of the program should not take more time than the actual functionality
That's rarely a reasonable expectation. Good usability is hard work.
> I figured out that for simple apps there is simply nothing better suited than Dear ImGui.
If you hate your users, sure. For anything more than a toy please use a real GUI framework.
> If you hate your users, sure. For anything more than a toy please use a real GUI framework.
Do you have any actual real criticism?
Dear ImGui's own readme recommends against using it for user-facing UIs. One showstopper is the lack of accessibility support.
Dear ImGui is nice but beyond basic styling, it’s not exactly quick and easy to style. It also lacks any kind of accessibility features, which is fine when you’re making tools for games or similar (ie highly visual tools), but if you’re making anything meant for a wider audience, you really should use something with solid accessibility support so stuff like screen readers work.
Also check out IUP. It’s lovely to work with and uses native controls. https://www.tecgraf.puc-rio.br/iup/
WPF is still a perfectly viable solution
> The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code).
I don’t understand how that makes WPF a non-viable solution. The author seems to have pretty strong feeling that it should absolutely be native code, but it’s not clear why
Yeah, I've done custom skinned apps in WPF that were deployed via zip file. Unzip and run the exe. Worked fine and even did p/invoke. Either they are ignorant about MS windows development or just a fanciful idea about how it should work.
Ooh I remember having a 'Windows API fundamentals' elective at college. I wrote an app with a couple buttons, menu and scrollable text area, but not much in terms of functionality, in pure C, that was all around well-behaved. It was more than a thousand lines.
"Writing GUI apps for Windows is painful"
Until you discover Delphi/Lazarus.
Some day I wish for someone to rebuild Lazarus with go and yaegi.
Then I would never use anything else ever again.
Lazarus' UI component library is beyond amazing, and growing up with it as a teenager made me realize how bad everything else is in comparison.
And C++ Builder as well.
Yes of course. Extending the Lazarus ecosystem to support more languages would be a killer feature.
> It would require me to write a custom paint function for every single control, which would take so much time I could raise a family in the meantime.
Implementing a custom paint routine is how you do theming in many UI toolkits. I get the impression the author is looking for a toolkit with declarative theming, like CSS.
Problem: It is extremely hard to stylize native Win32 controls.
That's not a problem, it's a feature. I am absolutely bloody sick of apps that go out of their way to reinvent the standard UI controls in perplexing ways and behave unexpectedly. Following the system UI preferences is what you should do, and it irritates your users if you don't.
There is a “hidden” dark mode for Win32 controls used by Windows File Explorer that you can activate, but it covers only some of the controls and still doesn’t look good.
Don't do that. If you use the regular Win32 controls then they will automatically get the styling the user has set.
I've been writing Win32 apps for close to 30 years now. It's sad to see the regression in UIs over the years.
> That's not a problem, it's a feature.
1000 times this. I want software I'm running to look like the rest of the OS (and every other application) and respect my OS-level UI preferences.
In the case of Win32 using the OS primitive controls mean that your application gets tons of accessibility and preference features "for free" (albeit Microsoft has done a good job in later Windows releases of removing the functionality to set some of these preferences).
There is no value add in making your app UI look bespoke. All the labor you're putting into that work is labor that could be better spent on functionality, features, and optimization. When I see an overly "precious" UI on Windows (owner-drawn controls, animations, fades, etc) I immediately question the ability of the developer to prioritize.
You seem to be in the minority with that thought.
The evidence is that most apps nowadays comes with their own style, often packed in a HTML frontend.
Users are used of websites which all have their own designs, and don't seem to mind if all apps have different look and feel.
Most users are unaware that there are UI standards, and have no basis for comparison. They use Google to help them figure out how to use apps, and take hand-written notes on how to find the things that they need. Once they figure out the functions in an UI that they need, they just pray that it doesn't change. The average user experience is horrific.
Devs that learned web frontend dev are not familiar with OS GUI guidelines. When I tell them Apple used to publish GUI guidelines for Mac application developers they stare at me in disbelief.
Most users have just developed a learned helplessness. It doesn't mean they don't like it.
> I want software I'm running to look like the rest of the OS
This is an impossible task on Windows, as it has multiple, inconsistent UIs by itself.
I want the apps I run on Windows to look like other Win32 apps. I want them to use native Windows controls.
All the UI "enhancements" in Windows 8 and subsequent versions are garbage and irritate me just as much as any other non-Win32 native UI.
As a mobile dev, it should be the same for mobile apps?
If you are on iOS, you could just use what Apple gives you with very little customizations. The app would feel right, dark mode, font sizes, screen traders, etc. accessibility would "just work" 98% of the time, the app would be fast.
On Android, things are a tad bit more complicated, but it still applies that the closer you are to the OS, the better things work out of the box.
But for some reason, companies, their designers, product owners, developers want to get creative, use their brand but eventually they always run out of time to implement things properly, so apps are slow, user's font scale settings are not respected, dark mode is a feature, and the app doesn't feel like part of the same phone / OS.
They also often want to use web technologies and/or cross-platform GUI toolkits, to avoid reimplementing their UIs.
And all because they fundamentally believe that their development time and expense is worth way more than their customer’s time and expense.
I strongly believe that the amount of ironing they have to do for that crossplatform toolkit takes more time than just going with a common core and different UI shells.
Netflix took this to an extreme, apparently porting WebKit to the PS3 just to power their app's UI.
With apologies for linking to such an appallingly spammy website, as I couldn't find a better one:
https://www.engadget.com/2010-12-07-netflix-ported-webkit-to...
Never coded a GUI app but speaking of regressions:
As a heavy windows KB user, losing the ability to alt+letter all the things to /quickly/ navigate windows apps is incredibly frustrating.
I've read that Mac OS envy infiltrated the WinUI time and while some may prefer the aesthetics, on Windows 11 apps like mspaint I can no longer navigate anywhere near as quickly.
From milliseconds to multiple seconds.
I'm incensed at this change personally, and I feel totally confused by it from the perspective of MS. In the era of AI and automation, slower screen draw times will make a significant impact to performance and energy use. I hope someone like Mark Russinovich, Kevin Scott, or Satya Nadella will notice and change course.
It's funny that you mentioned apple because their system shortcuts are integrated as hell and they even let you map them in the OS -> App level, way better than anything MS has ever shipped.
Yep, among other things both Apple-unique and emacs-esque text navigation shortcuts are in every native textfield across all apps and anything that's a menu item in any app can have its shortcut key rebound in System Settings without any extra work on the part of third-party devs.
It's one of the reasons why longtime Mac users are disinclined towards non-native apps. Most don't bother to reproduce these behaviors, and so when you as a user go to reach for these features that you have muscle memory for and they're not there, it's like hitting a brick wall in the middle of your workflow and makes the app in question feel basic and unrefined.
Don't forget you can type any of those menu items in the help dialog and it will not only tell you where it is, and not only let you activate it, it will helpfully show you the deeply nested set of submenus required to activate it.
Oh and of course those shortcuts are activateable by other applications to simplify app integration.
I sorely miss that menu search feature from macOS, even though it was unity's HUD on ubuntu that got me used to it in the first place. It's a shame it didn't become a more common feature, especially for programs with hundreds of options in the menu bar.
Annoyingly enough you don't really all keyboard shortcuts out of the box even if you build natively. If you create a Button(role: .destructive).keyboardShortcut(.defaultAction) in a SwiftUI dialog, you don't get Cmd+D as the shortcut even though Finder (and I think other apps too) uses Cmd+D as the keyboard shortcut for destructive confirmation dialogs. Thankfully at least a Button without destructive role will get Enter as its keyboard shortcut in the same context.
Yeah for now I keep most of my usage of SwiftUI restricted to non-Mac platforms. On macOS it’s fine for smaller bits like collectionview cells but has a number of rough edges for more major use cases.
It's never been better than what MS had and if you think so you've never used the MS way as I do.
Alt+underlined letter with no menus opens opens whichever menu maps to that letter
After which any [unique, as they mostly are] underlined letter activates the press for that menu item.
There is no equivalent to the speed of this in OSX, even with third party software.
Very very happy to be proven wrong on this
At least you can hex-edit or resource-edit the Alt+Letter back into a standard windows button or menu that's missing an accelerator key. Just add the missing &.
I'm confused by your alt key navigation in paint. I just opened paint and it still supports alt+key to do things in Paint.
No it doesn't. Alt+space bring up the window system menu to restore/maximize/close?
Alt+f, a to save as?
Negative.
Alt, f, a, p, saves as PNG, or j for jpeg, or o for other. Its changed slightly, but it is there.
Alt+space is still a shortcut, but it was repurposed.
You didn't "los[e] the ability to alt+letter all the things", they just slightly changed some of them.
It's even worse.
> Those were only a few options that I considered. After a very long time trying out all sorts of different libraries and at one point even writing my own MFC styles, I figured out that for simple apps there is simply nothing better suited than Dear ImGui.
They decided to go with the option that deviates the most from the standard Windows UI, where there are no native controls at all, and it's a nightmare for accessibility (see https://github.com/ocornut/imgui/issues/4122). I use it for prototyping privately, but I'd never make anything I want to release into the world with it.
Life was good with Windows 2000, GTK2 and MacOS9, styling was clear and had purpose. GTK and MacOS even had extensive Human Interface Guide documentation.
As a non-Windows user, I'm confused, maybe you can clarify:
> If you use the regular Win32 controls then they will automatically get the styling the user has set.
Does that mean they'll get dark mode if the system is in dark mode?
In which case I don't understand what the author is complaining about. Sounds like dark mode would be working as intended.
They want "easy styling" but I took that to mean things like icons, some colors, etc. Not totally replacing what buttons look like. I agree -- being consistent with the OS is a good thing.
They'll get dark, light, rainbow, whatever the user has set.
This was a feature since at least Windows 3:
https://news.ycombinator.com/item?id=25871787
I don't think this actually reflects the new light/dark mode people are referring to here. It will most likely always be the default theme - light.
Also changing those old themes has a good chance to "break" any (poorly made) apps doing their own themes. You could change some colors in the palette and parts of the UI could end up being difficult or impossible to read. Happens if the app uses a combination of palette controlled colors and custom colors.
Correct. For Win32 apps, the only official support for dark mode is some WinRT APIs to tell if it’s enabled, so you can “adjust your application's painting and rendering code to use a Dark mode color set”
https://learn.microsoft.com/en-us/windows/apps/desktop/moder...
> Also changing those old themes has a good chance to "break" any (poorly made) apps doing their own themes.
They already do this. COLOR_3DFACE has gotten brighter with each successive version of Windows and in Windows 11 is #F0F0F0. I've had to fix UIs that became unreadable as a result.
Those colour settings are not aware of Windows 11's "Dark mode"
Not surprising. Typical "modern" Microsoft. Reinventing things poorly is so common these days.
No, they won't get dark mode and this is the biggest problem for Win32 UIs now. If Microsoft would make dark mode available for classic Win32 apps, it would meet all requirements of the original poster.
The problem with this hands off approach is that Microsoft has not updated its base controls and does not provide some capabilities out of the box. It instead only offers modern controls via its Win UI 3 framework, which is squarely designed for C#.
I agree with you.
> Easy styling, including dark mode
I wonder if this requirement has been imposed from above.
When the web was taking off I received designs from the UI architect in the form of VB6 applications. Windows was the dominant platform at the time. Never mind it made no sense in the context of more fluid HTML layouts. This was before CSS.
Since then the web has probably trained the holders of the reins that they can violate user interface norms everywhere.
I don't know what the situation is right now, but for the longest time ever standard win32 controls where even less useful and more anemic than even the standard web controls. There was always a disparity between what the OS gave you and what the actual good controls MS Office team would think of (until ribbon, but the original ribbon actually did have a lot of thought put into it).
Who's going to tell him about C++ Builder (Embarcadero)?
No one wants to talk about it or Delphi anymore.
Programmers are just as fashion-concious as the Milan catwalk designers.
This. But flares are still waiting to come back in this case. To get my foot in the door writing windows GUI programs I often have to obfuscate the fact I am using Delphi (don't ask, don't tell) or work with clients without big IT departments.
Disclaimer - No clients were ever injured during this experiment.
Same
Wouldn’t that be excluded due to cost?
Native widgets which used to be wxWidgets' strong point, is now its Achilles heel? It is saddening, but the world moves on I guess.
Sadly the same applies to Lazarus/LCL too. Not only that, I had a nasty surprise recently when Fedora Budgie did not install GTK2 by default.
Win32 era was fun, for development and for reversing. But alas...
> The result should be a single .exe file with no or minimal dependencies and a size of less than 40MB
Computers come with a modern browser now. Instead of a .exe file, could it be, let's say, a single .html file with inlined image/css/javascript?
So much time spent on creating many different web frameworks to try and replicate the snapiness of native applications when the solution was to make native applications use web-tech so that both are equally slow. Mission accomplished! Genius!.
You just redicovered HTML applications from Internet Explorer 5.
Greetings from 1999.
https://www.developer.com/guides/ie5s-html-applications/
Yeah I thought of this too. Wrapping this with Tauri should not be too hard, and quite space-efficient
When people ask "why isn't there an awesome native widget set for my favorite language?" I have often said that GUIs are way, way, way harder than you think. It's easy to create a toolkit for your exact use case, but to create a toolkit that fits everyone's use cases to some degree is vastly, vastly larger than merely creating a programming language and a reasonable standard library. Vastly.
This is a great example of why. A small set of reasonable requirements and already almost all the options on what is probably the best-endowed OS for toolkits are almost all disqualified, and what did fit was an odd solution that won't work for a lot of other use cases. It isn't that these are unreasonable requests per se, it is that this is how this space works. Everybody has weird requirements of some sort, pretty much all the time, and getting even reasonable coverage is a huge, huge project.
Take a look at Win32 + Xaml Island. You will find that most problems in WinUI 3 gone.
Because Xaml Island is a "system component", you don't need to install or bundle anything. And unpackaged .exe is supported.
There's one problem, if you want to use Xaml Designer in Visual Studio: Because .xaml files are compiled and packaged into a "resources.pri" file. You have to ship this file with your .exe program. This can be solved by hooking system dll, see my project: https://github.com/ysc3839/SingleExeXamlIsland
It strikes me that having the C++ requirement is part of what makes this difficult. I'd like to have seen some reasoning why not to just use C#. Seems like it could have made some things easier, especially given the author's praise of XAML and acceptance of Visual Studio.
I'm not saying C# is better than C++, but just that choosing one over the other does have an impact.
> It strikes me that having the C++ requirement is part of what makes this difficult.
It doesn't.
In fact, it makes the problem even easier to solve due to the options that are already on the table. Virtually all .NET-based frameworks support C++ besides C#, specially WinUI3.
WinUI support for C++ is a travel back to the days of writing COM in Visual C++ 6.0 with ATL, only for a special bread of developers.
I work on several enterprise apps that are .NET but the GUI is a webcontainer with a web app. Unless there is something particularly high performance happening in the GUI, this works really well for several reasons:
1. We can update the gui without the user installing an update.
2. Lots of great web ui libraries, designers, and developers to make it look great.
3. Relatively lightweight
Unlike Windows, Apple and Android have managed to publish modern UI libraries for their own platforms - but in both cases, this involved migrating the whole platform to a new programming language (Swift and Kotlin, respectively). If I remember right, C# also has a few features which were only added to make Windows Forms and WPF more ergonomic.
I'm starting to suspect that general-purpose languages just aren't flexible enough to keep up with changing fashions in UI development. Whenever somebody comes up with a new UI paradigm, you're not going to be able to take full advantage of it until somebody designs a new programming language with that paradigm in mind.
If so, this might explain why the Windows team keeps pushing new desktop UI libraries, only to abandon them within a few years - they just don't have the willingness or resources to migrate away from C# and C++, and so the quality of their UI libraries is stuck in 2006.
The issue is the React paradigm, which is a bit questionable to begin with. It's a sort of fake OOP in a trenchcoat pretending to be something else, whilst abusing the language in ways that requires compiler plugins. My experiences with Compose and SwiftUI have been ... not that great. I kinda wish people would just have kept investing in their OOP toolkits.
You're right that reactive UI is a poor fit for most languages (especially JavaScript!), but I think the problem is more general than that.
Good UI architecture needs some convenient and efficient way to propagate state changes between different parts of the UI framework [0]. This requirement sits in an awkward place, halfway between imperative programming and functional programming. It just isn't in the day-to-day vocabulary of any mainstream language, not even modern imperative languages which have a bit of functional programming mixed in.
I don't think OOP is any better at fulfilling this requirement. Being able to offload half of your program into a visual editor is nice, but it's cold comfort if the other half of your program ends up being a tangled mess of callbacks and data binding.
[0]: https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
Yes you're absolutely right that these language dialects keep emerging because regular languages don't have quite the right features for reactive computations. Still, OOP was originally designed for GUIs and is a great fit for that, it's easier to build functional stuff on top than the other way around (apparently, judging from experience of having used both).
The closest I found to what I mean is that JavaFX has a whole observables framework, and there's ReactFX that builds a lot of stuff on top of it. With a small change that I prototyped in the past you can do what React Compiler is trying to do, where you run code and record what properties are read then register dependencies and re-run on change. It's quite a natural fit.
We already have a solution for most UI presented in this paper [1]. Functional programming let you represent the solution in a much nicer way after you've hidden the oop/imperative machinery away. But it's a complete package where the declarative part is only the shell. The UI part of any application should be considered as an external module, (like the data access layer) and the code architecture should reflect this. In an extreme way, if you can't create a telnet interface to you GUI software, that means your interface is already too coupled to the rest of the code.
[1]: https://dl.acm.org/doi/10.1145/62402.62404
Kotlin wasn’t designed with Compose in mind. They shoehorned it via compiler plugin.
The explanation is easy, the usual WinDev versus DevDiv politics.
Actually a lot of people are saying that Linux is the best platform for developing GUIs.
Every OS/environment should have a GNOME Builder equivalent.
Writing GUI apps for Windows in C++ is painful
There, fixed it for ya.
There are solutions if you're not hell-bent on using C++, be it .Net, Lazarus (FreePascal) or Delphi. We're using Delphi at work and for the most part it's super simple and easy.
Delphi comes with so many db drivers, a data layer that will let you do crud, and an app store that using it feels like cheating. Especially with devexpress controls.
> Writing GUI apps for Windows in C++ is painful
I don't think so. Qt makes this a trivial problem, and WinUI3 supports C++ as a first class citizen.
I'd argue that desktop development for Windows was never as good as it is right now.
I've used Qt a lot. Unless something very drastic has happened last 5-6 years it's not in the same league as say Delphi.
But fair enough, it's quite good. If I had to write a C++ UI application, it'd be on my shortlist.
Indeed, QML and C++ together are the best mix out there for GUI development. I've written my block editor completely using Qt C++ & QML: https://www.get-plume.com/ and it was a breeze.
Writing a gui in Qt is so simple anytime someone like the GP says “writing a gui in c++ is hard” obviously hasn’t tried.
lazarus is great, but the GUI library it comes with has the same issues that the author is concerned about... try changing the theme colors to a dark theme... you end up with something looking like crap with all the other controls using standard colors.
Writing GUI apps for anything is painful, if we’re being honest. To this day I haven‘t seen a single good GUI framework for any of the platforms that I‘ve tried. Flutter feels nice though
UIKit has a few frustrating details, but overall it stands tall above the competition.
For a long time the main downside was that you had to deal with Objective C, which is a turnoff for some people.
Swift solved all this, and writing UIKit in Swift is mostly a joy. Sadly now SwiftUI is the new shiny thing, and it’s a major downgrade in most dimensions save for a few.
A cross platform framework that reuses UIKit conventions and supports all modern languages (C++/Rust/Go/Python/Nim) would be the dream.
LuaRT (https://luart.org/) came up here a couple of months ago; would it meet the requirements?
This looks quite promising! I love LUA simplicity and I've always wondered if I could built commercial-grade desktop apps with it. So far I only considered something like LOVE, but LuaRT could be a good alternative.
I just write GUI's in tkinter (python), build a single .exe with nuitka, and interface with generalized application functionality either as a .dll or python module ..
tkinter may not be the sexiest way to do things, but its definitely productive in terms of the code-compile-distribute methodology, and it is very easy to wire up to a generalized 'daemon'-style abstraction, where the app logic is implemented as a daemon, sent application commands over a well-greased socket.
With this architecture, I no longer care that its Windows underneath - this is just another platform target - and can easily use either MacOS or Linux as the development environment, needing only to test on Windows, ultimately.
Anything beyond the sphere offered by tkinter is just less appealing. If I have to start treating a platform target in any kind of 'special' way, I just lose interest in that target, as a whole - however, from a UI perspective, Windows tkinter support hasn't been that bad, and generally keeps up fine.
(Disclaimer: if I really need performance, I also use the JUCE framework for my needs - even though its an audio-centric framework, you can build GUI apps with it just as well, and its also a cross-platform way to do things in pure C++ ..)
Oh god, seeing TkInter applications, and inevitably, having to fix them particularly on macOS just fills me with rage. Whoever reads this - do not use TkInter.
Whats wrong with tkinter? You're negative experience can't possibly be the standard by which 15+ years of productive use of it is to be discarded .. perhaps you haven't learned how to make beautiful UI's with it, but some of us have ..
You can easily go from Figma -> tkInter code -> app, too.
I have ideas about writing a GUI framework [1], but why in the world would I spend the time to make it up to the author's standards unless someone was paying me?
GUIs are a lot of work. People should be more willing to pay for work like that. Wanting everything free is one reason Big Tech has so much control.
[1]: https://gavinhoward.com/2024/05/a-new-architecture-for-a-gui...
The amount of bloat everywhere today is simply disgusting; just because my group server has 1 TB of RAM isn't a justification for letting a "hello world" app grow to more than 50 kB, GUI or not.
Yes, productivity is more important than squeezing out the last bit nowadays, but that the poster couldn't get his 40 MB limit satisfied shames the whole software industry. He should get a simple (i.e., half a dozen menus, dialogs, windows) GUI app done in 400 kB (it was possible in the past).
Apps developed for the modern (open-source) version of .NET may be compiled to a native code (NativeAOT). Some time ago, I tried AOT on a simple WinForms project and it worked. Unfortunately, functions using COM APIs are not yet supported (as they rely on reflection). There is an ongoing effort to fix this problem: https://github.com/dotnet/winforms/issues/4649
COM interop now works on NAOT with source generated COM wrappers: https://learn.microsoft.com/en-us/dotnet/standard/native-int...
(it's unfortunate the milestone is set to future in the linked issue though, which includes the light-up for the feature above)
One thing I learned about the software industry is that a lot of the tools we use are objectively horrible, but it doesn't matter because somehow big tech manages to shove it in our faces anyway.
Also, the inverse that really good software tools often don't see the light of day is also true. It really doesn't matter if some tool is good or bad for adoption. What matters is; does it have the backing of big tech? It shows that tech media is completely monopolized.
The painful bit is C++. I did a fair bit of that going back to MFC. Knocking stuff out in C# with WPF and WinForms was quite nice in comparison. I haven’t found anything nicer.
C# with WPF or WinForms only seems nice in comparison to other relatively painful tools IMO.
The old RAD graphical tools and newer ones like Rebol (that are now dated) show just what is possible. Mathematica is also pretty powerful and doesn't require a ton of code.
Totally agree with this.
I’ll get shot for this one but I write most of my GUIs in Excel these days.
Do you mean Visual Basic for Applications? How are you creating a GUI in Excel?
Mostly just locking fields. I don’t do anything procedural. It’s usually calculators, stats and modelling stuff.
I think there is a thing called Microsoft Office development kit or some other name that allows C# and other .Net programs to manipulate Office apps. Not sure if it's what the author meant, though.
Oh, I have used OLE (or some iteration thereof) to drive Excel from Python. That was a long time ago, but it sounds similar. I wasn't really doing GUI, though - I was using code to build spreadsheets from data files.
I had something I wrote in the 90s I wasn't proud of that was a word macro that read Excel sheets for a list of instructions and used those to compose documents and print them. I feel sick thinking about it.
Reminds me of Moe on the Simpsons saying I've done things I'm not proud of. And the things I am proud of are disgusting.
You should be proud like that.
I remember using Office Interop back in the day
Less useful these days as we use open formats, ie doc is propriatery, docx is open
> The painful bit is C++. I did a fair bit of that going back to MFC.
I'm sorry but referring to MFC while referring C++ is a telltale sign you don't really have any meaningful experience in the field. Developing GUI apps for Windows is a breeze with frameworks like Qt. You only suffer if you're a masochist, but the rest of us prefer to pick things that make sense.
I have a lot of experience, in the real world, which is somewhat less ideal than "just use Qt - it's a breeze".
How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts?
Aye you fuck off and work somewhere else that's what you do. Which is why it's still written in win32 native, ATL, MFC, custom GDI+ wrappers.
They paid two companies to come in and rewrite it, first in Qt which was a complete failure. Then in Electron etc, which was also a failure.
> How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts?
You're complaining about your personal legacy "chunks of win32 native, ATL, MFC, custom GDI+ wrappers".
Not C++. Just your personal legacy projects you didn't managed to maintain or update.
C++ doesn't magically rewrite your technical debt. You need to do your work.
For someone who demands so much of other people's open source, the author is quite unwilling to open source their solution.
Open source GUI libraries are lacking behind the gate locked, closed ones like Adobe. Even Macromedia UI back in the days 20 years ago looks way more appealing and polished than the current open source offering. The only polished open source UI in my opinion is Blender but apparently they have their own rendering engine built from scratch just like Adobe.
One would think that after three decades of the windows metaphor and billions of man-hours writing such applications, writing GUI apps (for any platform) would be a much more pleasant experience?
One could imagine a framework that would absorb all this historical know-how and turn GUI app development into a zero marginal cost exercise (fast, functional, cheap and maybe even pleasant) but who would push for this and why?
Maybe its a case of somebody not learning a lesson when their economic interest depends on not learning it?The overview of existing frameworks (including browser/webview based) suggests there is a sort of stagnating stalemate that feels sub-par but probably works just fine for those who have any leverage over the status-quo.
There is a UI framework which is fast, functional, cheap, and (depending on your personality) pleasant: the web browser.
HTML and CSS are go-to strategies not just because the web is the target platform for probably most if not almost all user interfacing software these days, but because HTML and CSS are very forgiving. Native UI frameworks are written by software engineers who demand type safety and XAML-like features which convert declarative syntax into imperative/object-oriented C#. The truth is that the vast majority of people who work on user interfaces are not the kinds of software engineers who enjoy this; HTML's model of creating arbitrary blobs of flexible dom nodes (and then using javascript to handle user interactions) is a lot more pleasant than getting compilation error after compilation error in XAML and having to google how the hell you display a set of items in a ListBox, only to have to filter through 4 or 5 different slight variations in the proper types between WinUI 3, WPF, UWP, and Maui.
Native desktop software will never beat web browsers as long as you're forced into using the framework's model for structuring your data and code. 13 year olds learn HTML, CSS, and Javascript, that should be the target for usability with native UI frameworks
There is certainly a strong case for the web platform as an all-weather gui platform but on actual mobile and desktops of here and now it is not a no-brainer choice. Its document oriented nature fits some use cases better than others. Not to mention that with the near exclusive focus on (incompatible) javascript frameworks it is not exactly clear even what "html" means...
It seems to have become the no-brainer choice. Lots of mobile apps just load html views, and probably most desktop apps I see these days are just electron apps. You can reason about the best use case for HTML vs XAML vs Swift, but it seems that the speed of development time and the insane amount of community support out there has made the web the clear winner
And the quality of software has gone downhill. HTML and CSS can be RAD, but they rely on millions of line of code in the browser engine while having subpar models for gui layouts and custom widgets. And building a native app is not that necessarily complex, it's just different.
The market prioritizes speed of development and cost of labor over runtime efficiency. Thus, until native app frameworks become easy and fast to develop for, we will continue to see everything turn into a web app
Writing GUI apps is painful, and being probably the most thankless area in Software engineering doesn't help either.
>The issue is that with bundling the .dll, it would still mean it being extracted somewhere
Hmm, this got me thinking about stuffing native code into CLR image. If you would just include additional executable code sections into PE, would loader map them normally? Or presence of IMAGE_DIRECTORY_ENTRY_COMHEADER would stop it from mapping native code? If so, maybe you could remove that header and manually do pre-XP style initialization, by calling _CorExeMain from imported mscoree.dll. Though you would need to somehow trick it into locating COMHEADER that we removed.
Or maybe I'm overthinking this and MS already supports that? https://learn.microsoft.com/en-us/cpp/dotnet/mixed-native-an...
As someone who spent most of the early 1990's writing Win32 apps, it doesn't seem like much has changed! MFC has always been a pain to use, especially coming from X and Motif.. even Athena widgets were better than MFC.
I've used QT in the past decade for MWL (Mac/Win/Lin) and it is a bit clunky compared to the graphical fluidity of Electron. We just need a solid effort to make Electron smaller. Granted, one can build smaller variants, but even 100 MB is far too large.
I'm a fan of a self hosted web service bound only to localhost, then you serve a HTML with all the bells and whistles from that web service. I think they used to call it OWIN. I guess the major downside is that you might get a localhost cert warning if you don't install a self-signed cert and a root cert in the PC's cert store (which yes, yikes)
It was a breeze, back in the RAD / Delphi days..
Nope, not at all. Winforms is still actively maintained and sports native advanced features like MVVM and async support. And winforms is not even the only option.
I disagree with the entire aeticle.
> Writing the GUI part of the program should not take more time than the actual functionality
I can't stand this mentality. The GUI is your functionality. The rest as far as the user is concerned may as well be pixies and fairy dust. Treating UI as an afterthought is why we've ended up with so much nightmarish crap these days.
What are the issues the author alludes to about AppX packages sucking? Looks like the new Fluent stuff wants you to use those. Curious to know what pain points exist there.
This was a big reason I switched to the mac many years ago. I was a win32 programmer professionally, but I was more productive on mac after a week or so of hobby fiddling around.
There is simply no contest. MacOS 10.0 was far superior as an environment to develop desktop apps when released, than Microsoft Windows is today with any toolkit you might want to choose.
I've had a good experience with JavaFX and I even managed to AOT compile two faily complex applications of mine. My advice would just be to stay away from FXML. Also use jlink to build a stripped down JRE for your application and package it with jpackage.
This reminded me of The Cherno’s Walnut library:
https://youtu.be/-NJDxf4XwlQ
First of all, this is an immediate rendering library which is a very inefficient way of rendering the UI for any application that is not a videogame. You are rendering the UI 60 times a second, regardless of whether something changed or not. Most UI frameworks only update when something changes.
Secondly, there are things in GUI frameworks that most people don't think about, such as accessibility. Windows has a builtin accessibility API where apps can declare the objects being shown on the screen, so that screen readers can interact with the application. I'm pretty sure this guys framework doesn't have that.
Pay for a professional tool and get RAD Studio (C++Builder/Delphi combo) from Embarcadero. https://www.embarcadero.com/products/rad-studio
There's a reason a lot of stuff is Electron.
I don't see Avalonia[1] mentioned here. Maybe that would work? It has AOT support too so should help with distribution and file size.
[1] https://www.avaloniaui.net/
The author would have been served extremely well by AvaloniaUI with NativeAOT target if they were willing to drop their assumptions regarding C# that are no longer true. (I wonder how well Uno Platform fares in comparison? It targets native controls first and foremost but is supposedly NativeAOT compatible too)
Uno is closer to a full stack rather than front-end in comparison with Avalonia.
A second recommendation for Avalonia. It deserves the acclaim.
Win32 + WebView2
Probably the best option for the author, bit surprised that this was not listed as option, especially since he considered writing HTML/CSS for Sciter.
Not an expert, but could you use something like https://enigmaprotector.com/en/aboutvb.html to virtualize a file system to create a portable exe. Not sure if the size would exceed your specs.
Tauri[0] is another HTML/CSS/JS-converter that generates small binaries by relying on the presence of WebView. Works pretty well.
[0] https://tauri.app
I don't see any mention of WinAmp yet. That app really whipped the llamas ass when it came to styling. And was super easy to create custom skins.
I'm all-on-board with look like the OS/platform but also, here's and example of custom styling done well.
> Writing the GUI part of the program should not take more time than the actual functionality
Oh man, I wish. No such tool exists. Adding a GUI to anything almost always at minimum triples the complexity.
While I have dabbled in a number of GUI libraries - many of them were a few years ago so covering my views on those would be disingenuous. I remember using Win32 or MFC.. and dabbled in Qt, etc.
In recent years, I have used WPF/Avalonia and while they are good - can lead to a lot of bloat following MVVM.
In the last year, I remember needing an application that shows a map. I tried to find support for openstreetmap and, while they exist, did not support what I needed to do. I tried Avalonia, and then GTK, etc. To be honest, I really liked GTK.. it just didn't have the tools I needed, sadly.
I have leaned to immediate mode UIs these days. I like I can create something with minimal code. Sadly, no openstreetmap support from what I can see.
In the end, I created a web interface. openstreetmap (leaflet) did everything I needed.
Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK.
It MUST be open spec. It MUST be free for all/any to implement. It MUST either be included or be in the primary vendor (MS, Apple, distro) software center.
A simple Hello World, click OK to exit the program application should be able to be cross-compiled for any platform, and the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does. It SHOULD be a small entirely dynamic program; possibly a few hundred kilobytes at most but even that seems too large. After all, it would mostly be the basic boilerplate of setting up memory, calling the system library loader, and linking in the shared libraries.
> need to agree on a GUI interoperability
I hope they don’t. I like that the different platforms I use feel and look different. In fact, I wish there was more variety. I wish there were still Atari, and Amiga, and BeOS, Tandy, and all the other interesting platforms competing for users with different ideas of how computers should work.
I wonder how possible it is to design a cross-platform GUI framework that not only uses the native UI widgets of each underlying platform, but also respects each platform's human interface guidelines. I'd imagine this would be very hard work, especially the part about respecting each platform's HIG, but the increased power of AI tools could potentially make this task easier. Such a framework could potentially be an appealing alternative to Electron for making cross-platform applications, with the benefit of conformity to each platform's HIG.
There have been many frameworks that offered this and some still do. But it comes at the direct expense of design discipline, branding, and user experience optimization -- all of which have been elevetated to high concern over the 15 years or so.
Cross-platform "Native look and feel" currently works for some no-nonsense professional utitlies and hobby tools, but mostly makes software that's hard to sell, document, or support.
Most have just opted for common widget libraries instead, and frameworks have stepped up by providing rich libraries of such widgets and prioritizing features for customizing or complementing them even further.
I’ve been thinking more lately about a library which defines an interface for GUI elements, and then leaves implementing that up to you. Something like MVC (or some other design pattern) where the view part is an interface definition.
wxWidgets does this pretty well, e.g., wxSingleChoiceDialog has "OK" "Cancel" on Windows but "Cancel" "OK" on Linux/GTK.
I think OpenStep actually had something like this in mind and had a Windows implementation too. It's apparently even used in Apple Windows apps like Safari, but of course it must not be complete enough to be able to fully replace native Windows API, and the incentive isn't there either.
There was an implementation of OpenStep for Windows named OpenStep Enterprise:
https://forum.winworldpc.com/discussion/11422/openstep-for-w...
It even survived Apple's purchase of NeXT, where the OpenStep API was renamed Yellow Box. There was a port of Yellow Box to Windows:
https://www.betaarchive.com/forum/viewtopic.php?t=29049
In both OpenStep Enterprise and Yellow Box for Windows, while the UI elements still have some NeXT-isms, it's not terribly out of place, either.
However, this got scrapped sometime when Apple abandoned Rhapsody (which had PowerPC and x86 versions) in favor of Mac OS X (which was originally only available for PowerPC until the Intel switch in 2006, though Apple maintained an x86 version internally during the PowerPC years). During the transition from Rhapsody to Mac OS X, Yellow Box was renamed Cocoa.
The impetus here is that Adobe had initially promised a free, then low-cost license for Display PostScript --- when that was pulled, Apple had to come up with an alternative --- that and the fact that all the major app vendors announced that they weren't willing to do top--to-bottom re-writes using the NeXT frameworks (there was even a rumor that "Yellow Box" was named for the sake of Bill Gates' comment, "Develop for NeXTstep? I'll piss on it.")
So, Apple, led by Mike Paquette and many other talented folks from NeXT created Quartz (née Display PDF) and Carbon and instead of a consistent environment with a single API, we got an assemblage of technologies which had a Calculator app written in Java which took _forever_ to load, a Finder written in Carbon instead of Workplace.app, and icons cluttering the desktop and a Sidebar instead of a Shelf, and a bunch of Carbon apps.
> Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK.
I've been saying for a while now that the open source world would have benefited if more effort than what went into GNUStep had been focused on copying Cocoa to the point that it rather than GTK or Qt had been the toolkit of choice for the Linux Desktop. Especially when there was a major infusion of interest circa 2010 of folks adopting the MacBook Pro as the developer machine of choice.
I think it's still doable. And I mean down to looks, too, and not just API feel. Aqua from the same time period (Snow Leopard through Mountain Lion era) is the closest thing I can think of to timeless visual design.
It's true that if everyone just made Cocoa apps that looked like they were created with Mac OS in mind it would look out of place on Windows and elsewhere, but (a) it would still look rather good, and (b) it would not look any more out of place than anything else, including Electron and even lots of "native" apps, due to the proliferation of toolkits described in the article not to mention the Gnome identity crisis that has only just recently begun to get reigned in—mostly by following Mac OS cues and being more consistent than before. It's just a shame that it stops at the surface level and doesn't carry over into the actual APIs. Plus those cues are from the post-flattening of UI.
If anything is going to get copied by Linux as is... it'll be Win32 API so mono / C# stuff can bind directly to that, and Mac/OSX will be even more isolated.
For something to be portable everywhere it'll have to be an industry standard that the existing industry buys into.
This exists. It's called wxWidgets. It's an API shim over native components plus some convenience classes for abstracting out OS-specific functionality. It's LGPL with static linking exception, so no DLL hell.
I'm not quite sure what you mean by open spec, but it's just an API not a protocol, and uhhhh.... https://caselaw.findlaw.com/court/us-supreme-court/18-956.ht...
The library exists, BUT it is NOT shipped natively and NOT (AFAIK) something which trying to run a random downloaded utility app will trigger the system library loader prompting for the 'common wxWidgets runtime, for free, codesigned by Microsoft' download and install from the store to run the app.
Your previous post said
> the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does
If there's no DLL required then why does it matter if the DLL is automatically downloaded from the Microsoft store? DLLs are not useful for statically linked binaries.
That's called WINE. ;-)
Win32 Hello World messagebox is a few hundred bytes.
they don't need to do this and likely don't care to. web ui exists. microsoft doesn't even care about native anymore. they are focusing on .net maui cross platform/web (with blazor) stuff and AI.
the days of snappy portable applications are over. unless you want to stick with win32. and nothing wrong with that. in win32, you have the tools to create any look and feel you want. the author just doesn't care put in the time to do that and wants something pre-built while conforming to his demands.
Don't ,don't say that,every time you say that windows gains another guiframework that precents fixes to winforms,the only one they support..
On the rare occasion I find myself needing to write a windows gui, I just use winforms. I don't have to muck about with XML nonsense and it just works.
>Alternatively, you can buy a commercial [Qt] license for several thousand dollars.
There is a small business option that is cheaper. But probably still not appropriate for this project.
A. If a gun were placed to your head and you had to write a native Windows app, what stack would you use?
B. And, if you had to write a cross platform app, which framework would you use?
If money was not an issue, I'd probably try Delphi for both A and B, which can create native cross platform apps.
If not, I'd try Lazarus for A and Kotlin compose for B A: Lazarus or Delphi (if money was not an issue)
B: Kotlin compose or Delphi (
I presume we are talking about GUI programs:
A. Delphi --- easy choice (or C++ Builder if I had to use C++) B. Also Delphi --- it supports macOS (arm64 + x64), Linux, and Windows
If I have to write a CLI app, I'm probably picking Go or Rust.
A. imgui and SDL2
B. imgui and SDL2
That's not what I asked...
A. PureBasic
B. PureBasic
libui libui
Just use Godot (https://godotengine.org).
There's tools to pack dependencies into a single executable, that then extracts those dependencies, as necessary, upon execution.
The requirements are strict.
For myself I rarely write app. Most often I self-host programs. GUI is managed by a browser.
“Stylized”
Let me stop you right there. No.
Leave the OS to style controls how it does, for consistency. There is no reason to be inconsistent. This is not 1994 and you’re not writing a warez keygen
Styling functionality doesn't have to imply introducing a new look and feel, it might just be needed for extensibility.
Lazarus and Free Pascal might work here.
it won't. at least not with the color theme requirements. and if you don't care about those, you might as well use win32 controls.
Did someone suggest Flutter yet?
write a cross platform GUI is even more painful.
It's pretty much either paying for Qt or use the bloated Electron.js. Looks like the latter won the market.
I failed to see other practical options, flutter was an option, but its strength is not on desktop so far.
What was your problems when using Flutter for desktop? For me, it's the lack of multi-window support. There's a community solution but it's a bit lacking because it spawns another engine while the upcoming official solution uses single engine.
I personally use it for my desktop apps (cross-platform) and building UI for it is a breeze. Though I forked someone's window styling plugin because it's missing some features I need. A native dev would've done better than me but if it works it works I guess.
If I had to satisfy the requirement in the post though, I'd use enigma protector with to make the app folder into a standalone exe and with compression enabled to make it smaller.
Wouldn’t Electron solve this problem?
Build a web app and use Google V8 with your c++ code.
Writing anything for Windows is painful. Writing it on Windows is even painfuler.
Shoutout to the Rust library `iced` which is cross-platform, amazing, and can do anything you need it to at blazing fast speed and low memory footprint: https://github.com/iced-rs/iced
I've been using EGUI to write GUI programs. Works nicely and runs on both Linux and Windows without notable differences. (I haven't tried Mac, but it presumably will work there as well without changes). Small binaries (a few Mb), and can integrate with maps, 3D rendering etc.
Yes it also works on MacOS, and web as well.
I don't do a lot of desktop apps but for simple GUI apps I've been using Python and Pywebview, with packaging left to Pyinstaller. The main reason is that I get to reuse the python/javascript/css libs that I know, and it's easily portable. I'm sure a native app uses less memory and cpu but frankly what I get with this combination is not that resource hungry. In fact, anytime something goes south it's my fault for using poor algos. Also, there are tons of great GUI libs and web components.
I was going to suggest embedding the native WebView ActiveX control (which I did in the past with great success) but it turns out the WebView has been updated and wants end users to download and install the Chromium-based runtime library nowadays.
Delphi is the superlative windows desktop development tool. It does support styling and just about anything else you would want. There is a free alternative in Lazarus but I don’t know if it supports styling
I've been a strong lover of Qt, but I've just undestood that one cannot statically link it. Tbh it's never been the case in my situation, usually writing in PySide bindings which will never link dll/so libraries, however in certain situations this would get really expensive, if static linking would be required.
It took a horrendous heat to make a programmer find the best GUI library, but it was worth it! 500KB for imgui? Seriously? I remember Inno Setup creator saying that we was compiling his 'boot' application (to reduce size, because it was glued as a prefix to a zip file) in Delphi 2...How about gtk?
I love GTK, but compiling it on non-native platforms is torture. If you're lucky enough to get a build environment working, compilation can take hours just to yield a horribly buggy and slow GUI.
I really wish GTK worked better cross-platform, but I mostly use it for Linux-only stuff. It's not humane to make Windows and Mac users suffer through it, unfortunately.
Tested Geany Editor on Windows the other day, it uses GTK, great editor but horribly slow on Windows, just scrolling a small file (less than 100 lines) was sluggish.
MSYS2. And copy over prebuilt dependencies. And while we say C++, I suggest always to use Meson as build tool. Which allows you to use WrapDB (built in dependency-manager) aside from available native libraries and own local sources.
MSYS2: https://www.msys2.org
Meson: https://mesonbuild.com
The problem about Windows is, that Microsoft adds new APIs repeatingly and doesn’t care much about the previous ones. While on Linux we’ve Gtk1, Gtk2, Gtk3 and Gtk4.
And while people complain about deprecations and changes they actually mean „API changes require work to use the new major. But these people keep maintaining it. And provide upgrade paths to enhanced versions? I’m in!“.
HiDPI, Wayland, new Widgets, new renderers and a scene-graph.
PS: If you need to keep it small and simple and address professional (power) users I suggest a TUI with the venerable ncurses. Or notcurses.
Notcurses: https://github.com/dankamongmen/notcurses.
Demo of Ncurses (For the lulz): https://www.youtube.com/watch?v=dcjkezf1ARY
GTK programs look very out of place in Windows.
Tried Decker?
Frankly Qt is the only sane option. Just give up on the "single static exe" requirement. Your users will have to unzip a zip. Hardly a big deal. Certainly not worth switching your entire stack to something vastly inferior for.
>As a fellow European, I do not have air conditioning.
Is anything stopping the author from buying a heat pump?
Depending on if he lives in a apartment some country/cities have laws against doing any work in the appartment that impacts the outside without permission from the house owner.
E.g. you can buy a heatpump but you can't drill the hole in the outer wall.
In germany and austria most if not all windows also either open fully to one side or basically bend inwards so you can't install the ac units you install directly into the windows[1].
[1]https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F...
edit: qualified the law statement
Are portable AC units not available in Europe? They are inefficient but can sit inside next to the window and only require that you partially block off a window opening.
Power isn't cheap, and inefficient is an understatement. In the heatwave last week in Germany I managed to get ours to cool a tiny bedroom from 30 to maybe 26 degrees Celsius.
Doesn't help that in new construction outer walls are usually very well insulated, and inner walls and floors aren't (by design; 70% of total heating cost is evenly split too), so you're working against your neighbors too. We have some stupidly complex building standards often driven by industry lobbying (which also makes building expensive), but installing a mini split hasn't made it on the list.
They definitely exist, and are very cheap. I got one for 200, gave away to a friend when I moved out of an attic apartment. They have a window-attachment accessory that makes it easy to attach to those European windows.
The real reason most of us don't have AC is because it's hot for a very short period. Last year it definitely wasn't too hot for me to warrant having one. This year so far, it was, for a week: we had about 30°C (86°F) last week, but next week my mobile phone promises it's gonna be 20°C (68°F) maximum, which does not need AC. Maybe that will change, though.
I don't know what landlords are like in European countries, but some landlords in America forbid people from connecting any kind of AC exhaust port to a window.
It's funny that in this case the law now protects you.
Generally anything you do indoor that falls under normal usage(painting walls, hanging furniture with big screws,etc.) is ok without approval, at least in my country/city(austria) and the land lord can't deny any of this and is not even required to be notified.
As you would have an open window and a not so noise machine running this would be ok, but energy efficiency is quite bad and you lose the benefits of the thermal insulation of your building.
Can you name one place where this is an enforceable rule?
Yeah, the GP comment is classic HN. Wildly vague, with no supporting evidence. The planning rules in the US are fractally complex compared to "Europe".
They are but not as efficient and so most people don't bother(that I know of).
Works just fine, I have 8000 BTU and it cools a living room very efficiently. I need it about one or two weeks per year in Finland. I can't imagine anybody working from home without one, even as north as Finland. Although we Finns are probably least used to heat so even 27 celsius is unbearable.
The only thing one needs is a window-sized cardboard with a round hole and blanket if your target room has no door. I just looked at prices and 10000BTU seemed to be ~350 euros.
I bought a portable split system for 2400 EUR. Works pretty well since I have shutters and a balcony, I put the external part outside the window, pull down the shutters and seal the lower part of the window around the pipe with some stuff. Doesn't use lots of power if I cool to 26C. Well, today we had 34C outside, so it had to work a lot.
2400 EUR? Cripes, that is expensive. Do you mind to share the model?
Sure thing: https://www.amazon.de/-/en/gp/product/B07YZ5XT92/ Maybe it was a bit less, 2200 with shipping. I do have a top floor apartment looking south, so I get a constant 30C+ in summer, without any cooling at night.
They are available
Swamp coolers are cheap and don't need a window or drain.
It can be hard to justify the cost of installing and maintaining any form of household cooling in colder areas of Europe. Additionally a lot of apartment buildings don't have them, and most landlords probably wouldn't appreciate a tenant installing one without permission. Evidently heatwaves are becoming common enough now that most people should probably keep a window AC unit ready in case of emergencies though.
As an European from Spain, in south European countries air conditioners are essential(Greece, Spain, South Italy, South Spain, inner Portugal). But in other countries or places it is not really necessary(north of Spain, France, UK, Germany).
Some days of Summer it is hot there, and they are not prepared for that like people of the South of Italy or Spain, and there is chaos.
It is like when it snows heavily in Madrid: https://en.wikipedia.org/wiki/Storm_Filomena In places like Austria or Switzerland it would be routine. They are prepared and it would be not a big deal, but in Madrid it stopped everything for two weeks.
Usually, living in an apartment.
He also says it's 32C, which is slightly less than 90F.
Interestingly, some people would describe that temperature as only "warm". I recently watched a video of a machinist working in his shop (southern US) saying that it was 94 and "a little warm".
WX Widgets still exists.
> Problem: When linking dynamically, there are a myriad of different .dlls required to run the app, totaling over 40MB.
Is 40MB a lot nowadays? Eg the argocd cli is 155MB, and that's just a relatively simple cli app that as far as I know just calls a remote api.
Welcome to bloatworld I guess.
Did they try JUCE?
Unfortunately, if you are insisting on a single exe file, then you have to be way more flexible on your requirements than the author is. There’s a reason that practically every Windows program has an installer. It’s stupid and a waste of time but also probably more of a waste of time to try to be the exception to this rule.
Frankly I don’t see why C# targeting an old (3.5?) .NET framework version wouldn’t work for the author. There seems to be a tendency to fixate on how things should be vs where we are now. C++ native GUI dev is not a mainstay like it used to be.
I agree with the sentiment of your post.
Real question: Is a single exe not possible when targeting .NET Framework 3.5? Or is the problem that the sum of their silly requirements makes it impossible?
It should be quite possible to target .NET 3.5 and hit all the other requirements, except native C++. They hinted at this and then started talking about C++/CLI. If there’s ever a tool of last resort, that is it.
Qt is the hero
Microsoft: Here are cool windows for Windows.
Microsoft: Oh, yeah, to use it, you'll need to deploy it with the Microsoft Store.
"Problem: It is extremely hard to stylize native Win32 controls." No. Don't style them. Let the users settings dictate how your app looks. This is the correct way.
I would like to show my appreciation to the author of this blog, although a lot of comments here show otherwise, as the restrictions the author has involved here are considered as "unrealistic" or "unreasonable".
Whenever an article is trying to compare several options, it is very important to know beforehand what the author is trying to achieve, and what the restrictions are. And in this blog, the author has clearly stated that the restrictions are to develop a GUI within 40MB and should be easy styling. No one should judge the author for the restrictions, as it may be from the author's specific needs, or directly come from the client's requirements. The clear restrictions are also very helpful for readers like me to understand the trade-offs the author has made, which is not something that I have to do myself, but I can definitely learn from the author's experience. If I am in a similar situation, or even with different restrictions and need to make a different trade-off, the author's experience can still be very helpful for me.
Just want to call out that it is not a fair ask for a blog post to exhaustively compare all the options, as it is very time-consuming for even a paying job. We learnt the specific restrictions that the author is facing to, and we learnt the author's experience with the options that the author has tried. That is already a lot of value that the author has provided to us, and I would like to thank the author for that.
[flagged]
ah, the intersection of 2 anti-patterns: GUIs and MS Windows. lol
The solution you end up with will be a compromise on your requirements. E.g. if you can compromise on the 40MB size requirement then Electron should be a good fit to cover all your other requirements.
Microsoft has developed VSCode with Electron.
https://www.electronjs.org/
> if you can compromise on the 40MB size requirement then Electron should be a good fit to cover all your other requirements.
Microsoft also supports React Native, which is arguably way better than any webview-based approach.
Unfortunely it is built on top of WinUI 3, with all the warts it entails.
Mostly because since they killed C++/CX, there is no UI tooling story for doing XAML C++, without having to deal with IDL COM like mess in Visual Studio, only worse in WinRT case.
> Unfortunely it is built on top of WinUI 3, with all the warts it entails.
I'm not sure that's relevant. The whole point of React Native is that you do not touch the underlying framework. Instead of churning out XAML, you just write React and let the framework bother with how the GUI is implemented under the hood.
>WinUI
>modern Windows components
I swear to God if I ever downloaded a piece of open source software from GitHub, opened it, and saw the deformed Windows 8 Metro UI gawping back at me, I would do everything in my power to wipe the blighted individual responsible from the face of the fucking Earth