Comment by apankrat
15 days ago
Let me chime in and say that plain Win32 API is a perfectly viable option if you are using C++ (or another "OO" language) and if you are willing to sink a couple of weeks into writing your own MFC-like wrapper.
Clearly this is not an option for those who are just starting up with Windows GUI work, but with little experience it is really a matter of 2-3 weeks of ground work and then you have full control over all nuances of the UI, yours to extend and mend as you wish.
If there's one thing that Microsoft is really good at, it's ensuring deep backward compatibility. So anything that's based on Win32 API is going to be stable. If it works now, it will work later.
I have some examples from 10+ years of development updates accumulated here - https://bvckup2.com/wip
The main thing that's hard going down this route is dark mode support. The Win32 USER and common controls just don't not support dark mode, but are actively hostile to it due to the amount of hardcoded light colors and backgrounds in the system. All of the system colors are light regardless of the dark/light system setting, highlights are hardcoded to light blue, disabled controls use a hardcoded color, half of the window messages for changing control colors are silently ignored with theming is enabled. Menus are among the more difficult to deal with as they require extensive owner draw.
On top of this, there are a small handful of system UIs that do support dark mode and make your program look inconsistent with dark mode regardless. Message boxes will switch to dark mode, and so will file dialogs -- which is a problem if you've used the Vista-style customization, as any syslinks will appear in a color of blue that's hard to read against the dark mode background.
First, dark mode is for people who set their screen brightness too high.
Second, win32 is designed with the ability to change all the default colors and you used to be able to do this by right clicking the desktop and selecting "properties". If dark mode doesn't follow this - just another symptom of Microsoft's siloing incompetence. The team that wrote dark mode may not have been aware that this feature existed because parts of the platform are so disconnected from other parts.
Dark mode for apps is a setting in the OS and a general expectation now, it's suboptimal to ship a new UI that doesn't support it. And, again, Win32 message boxes in your program will switch to dark mode whether you want them to or not.
Win32 controls ignoring system colors goes much farther back than dark mode being introduced in Windows 10. The theming engine that broke a lot of that functionality was introduced in Windows XP. Beyond that, there were always a few hardcoded colors like disabled gray text going back to Windows 95.
Dark mode ignoring Win32 system colors is not incompetence. It was _intentional_. Dark mode was introduced by the UWP side, which intentionally did not extend it to Win32. To this day, there is not even a Win32 API for desktop apps to query whether dark mode is even enabled. The official recommendation is to compute the luminance of the UWP foreground color setting:
https://learn.microsoft.com/en-us/windows/apps/desktop/moder...
11 replies →
> First, dark mode is for people who set their screen brightness too high.
Not at all. It became popular mainly because as part of the spread of the flat UI epidemic, the previously non-optional “light mode” OS UI themes all shifted away from midtone colors to blinding stark whites. This meant that monitor brightness settings that had previously been comfortable suddenly weren’t.
On top of this, modern flat UI light mode themes consistently have poorer contrast and delineation than their dark mode counterparts, because higher contrast with darker grays makes flat white UI themes appear “dirty”. So even if the brightness isn’t an issue, your eyes have fewer visual cues to guide them.
Aside from that, on IPS panel monitors lowering brightness past a certain point also greatly lowers color vividness which looks bad, which is why some of us like to keep it maybe not maxed but a bit higher than is comfortable with light mode.
It is not. I have some issues with my eyesight and dark mode makes it easier to use a computer in some lighting conditions. So for me dark mode is an accessibility feature. And yes you could use the ugly recolor feature windows has but dark mode does the same thing and looks better most of the time cause a UI designer actually looked at it.
> dark mode is for people who set their screen brightness too high
There can be other valid perspectives than your own.
I don't think your brightness sentiment is universally shared by most people, hence the downvotes. I think this comes from one particular study that people just end up parroting, possibly via third-hand gossip.
While a sufficiently low-brightness screen might have some specific advantages to dark mode, I think the issue is more nuanced than that.
First, not everyone can set their brightness to an appropriate level.
If the user is prone to migraines or light sensitivity, light mode even at a low setting could trigger headaches.
Light mode also produces significantly more blue light, which can have health side-effects as well.
If you keep a white screen on at appropriately low brightness in a dark room, the relative difference between the screen and the surroundings is still massive. This creates pupil strain as the eye constantly adjusts. Dark mode aligns the screen's luminance closer to the room's, reducing this strain.
Dark backgrounds make colors pop more vibrantly and prevent the "washed-out" look that can happen when bright images sit on a white background. It can also reduce halos visible around bright objects in photography apps and make the UI less distracting.
For battery-powered/mobile devices, dark mode uses much less battery power on OLED screens.
Judging from the screenshots, that doesn't produce Windows 11 style UIs, right? I.e. it contributes to the problem exploree at https://ntdotdev.wordpress.com/2023/01/01/state-of-the-windo...
Maybe I grew up with Windows so the older uis don’t phase me, but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland. The average Windows user might stumble on an aero dialog, which is arguably less jarring in win11 than og metro.
> but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland
I've been around long enough to remember MS and their fans banging on about how bad other OSs were for their inconsistent interfaces, so I feel justified in getting a little riled at the hypocrisy of how much of a mess UIs are in Windows these days.
And I don't see it getting any better - they'd rather spend the time finding new places to slip in adverts. And this is far from the fault of app developers, while they often do have something to answer for wrt consistency, because the worst culprit is MS themselves both in their apps and the OS.
I shouldn't have to click to make sure the right thing has focus for instance, particularly after switching from another virtual desktop, I should be able to see this information easily but there is no consistency in titlebars and other window chrome any more.
Screenshots are made on Windows 8.1 box, the windows chrome comes from there.
Plus the whole thing is meant to work on ancient Windows versions (like, Vista and WS2008 ancient), so that ultimately defines the minimal common UI denominator.
Many would consider that a positive.
Jesus, that's way worse than I expected before clicking
The last time I built a native Windows app years ago, I used WTL 3.0. It’s a light weight wrapper on the native Win32 API, lighter than MFC. It took out the unpleasantness of working directly on Win32 API and wrapped it in a simple OO framework. It had access to all features of Win32. It could produce runtime binary in dozens of K, instead of MB or GB.
Microsoft released it open source later on. Looking at the repository, looks like it has been kept up and maintained, up to version 10 now.
GitHub mirror of the sourceforge repo: https://github.com/Win32-WTL/WTL
WTL delivers very small and efficient code, very close in size and speed to SDK programs, while presenting a more logical, object oriented model to a programmer.
Why not just use C++ Builder or Delphi?
Presumably because they don't support C++23
I don’t want to be that person, but if you can think of a decent API for your MFC-style wrapper, an AI should be able to write a decent implementation for you.
Agreed. In fact this supports the GPs point about using the rawest form of GUI manipulation.
For years we loaded up libraries and abstractions to minimize boilerplate. These hid the actual underlying mechanisms and often made specific customisations harder to do since you were taken away from the raw functionality.
These days AI is extremely good at writing boilerplate and in my opinion explicitly typed out boilerplate code is much easier to reason about than a library that abstracts things away to a one line annotation or similar.
A good example is that i've recently been leaning back to the raw Android apis for things like recyclerviews etc. It used to be 10+ files to changed to create an efficient scrolling view on Android with various resources and adapters required. So a whole bunch of libraries came out to try to abstract the complexity away. You know what though? I don't care about that anymore. I'm going back to the raw GUI APIs where possible because it's so explicit and clear even if it's 10x more code.
> If it works now, it will work later.
Wine is better at it than Windows itself. Especially for really old programs.