Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there. Yes, the same vendor provides other toolkits.
Linux is a kernel project, and different distributions are for many purposes best considered to be different OS's. Desktops based on Linux mostly are either GTK or QT, and so the native toolkit depends on the desktop you are using.
Is this too much fragmentation for users on those platforms to realistically expect commercial software to support them natively? Yes, of course, but that doesn't mean there is any confusion about what it would mean to do so.
Win32 is no longer the native GUI toolkit on Windows, given how much of the OS GUI itself is not using it (new Settings etc). If the argument is that it ships in the box, well, so does UWP XAML.
Is that useful pedantry? From context, you really think that's my confusion here? I didn't include *BSD either, but it isn't any different for the relative handful of people using that for a desktop system.
> Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there.
Except for Microsoft's numerous attempts to supplant it and the fact that the base OS doesn't even use it consistently for their own system. Microsoft's own File Explorer and Settings app that only had to live along with Control Panel for a decade, was that not native? They aren't "Win32".
If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API. Nobody casually calls it USER though, and the bulk of people still targeting it do so through .NET these days via Winforms.
If native just means provided by the vendors base system, ok, but then if there are 10 different forms of it, other than the distribution issue there isn't some great intrinsic benefit over just targeting Qt or Flutter. Especially when someone like Microsoft can't settle on a consistent design language through the years.
> If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API.
I don’t think it is “anachronistic” - as far as I am aware it is still the official name. And I don’t think calling it the “Windows API” is right, since Win32 is just one of the APIs that Windows offers. If I’m calling CreateFile, I’m using the Win32 API, but if I’m calling NtCreateFile, I’m not using the Win32 API, I’m using the native NT API instead. If I set the subsystem as NT instead of Win32 in my executable’s PE header, calls to native NT APIs such as NtCreateFile will still work fine, attempts to use Win32 subsystem APIs won’t. And there are other APIs Windows has which aren’t (strictly speaking) part of either the native NT API or the Win32 API - COM and the many APIs built on top of it, .Net, WinRT, DirectX, etc.
But you are right that Win32 isn’t a GUI toolkit. It contains a rather basic and old-fashioned GUI toolkit (USER), but it contains a lot of non-GUI APIs too. I’m reasonably familiar with those parts of the Win32 API used by services and console mode apps, but if you asked me to write a Win32 GUI event loop I’d be asking ChatGPT to remind me how, because while I’ve read tutorials I’ve never actually attempted it.
The name itself is anachronistic, what does the 32 stand for? You call CreateFile with 64-bit pointers, it was still considered Win32 (until they officially changed it).
"Using the Windows API, you can develop applications that run successfully on all versions of Windows while taking advantage of the features and capabilities unique to each version. (Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)"
The API provided by ntdll is semi-officially called the "Native" API and much of it is subsumed into the Windows API. The PE subsystem names you are referring to are IMAGE_SUBSYSTEM_NATIVE and IMAGE_SUBSYSTEM_WINDOWS_GUI/CUI, so it's somewhat consistent.
Microsoft officially refers to that API as Native System Services in the documentation for the DDK.
Microsoft’s docs are a self-contradictory tangled incomplete and sometimes even downright erroneous mess, I wouldn’t put too much stock in what they say.
If I say “CreateFile is the Win32 API analog of NtCreateFile in the NT native API”, everyone experienced with low-level Windows development will know what I am talking about. If I started talking about “Native System Services”, I’m not sure as many would.
Similarly, the distinction between APIs which are easy to call from C code (and simpler FFI frameworks from scripting languages, e.g. libffi) and COM/Automation/.Net/WinRT APIs which are a lot more difficult to use from C (as opposed to C++), and which require more advanced FFI support, is still important in Windows development (or at least some parts of it.) And in practice the term “Win32 API” is often defined to exclude those higher-level harder-to-call-from-plain-old-C APIs.
It goes back to the original design of Windows NT, where you had a primary environment subsystem (Win32), secondary environment subsystems (OS/2 and POSIX), and integral subsystems (local security authority, session manager, etc). The primary environment subsystem is still called Win32, and the Win32 API is its public API. (It also has private APIs, most notably the CSRSS LPC interface, but that’s unstable from version to version.). As I said “Windows API” is insufficiently specific because (especially nowadays) Windows has lots of other APIs. WinRT and Win32 are both Windows APIs but very different. WinRT is largely built on top of Win32, but some documented WinRT APIs are built on undocumented Win32 APIs, leaving WinRT the only officially supported API to access certain functions.
Microsoft intentionally didn’t rename Win32 to Win64 when they added 64-bit support because it is 99% the same API just with some highly regular changes (mainly widening pointers). By contrast, Win32 was a much more radical change to Win16 - the Win16 API directly incorporates notions of segmented memory, which it uses to implement movable memory blocks (rather similar to Classic MacOS, albeit that did it in a 24/32-bit flat memory model rather than a 16-bit segmented one). Microsoft could have done a more straightforward port of Win16 to 32-bit x86, e.g. using a 32-bit segmented memory model instead of 32-bit flat memory, keeping movable memory; but (thankfully) they didn’t. It would have made it a lot harder to move to 64-bit or non-x86 platforms.
GTK 3 or 4? Xfce+MATE+Cinnamon are still popular enough options and I used the former for years.
GTK itself isn't even a well defined target.
And GTK3 apps of which there are plenty do not appear native in a modern GNOME desktop much more so than a decent Qt app does.
The thing is that people in the real world talk about Linux support for an app, as in Desktop Linux support, and the only common denominator there for years was basically X11. I have heard exactly no one ever ask, oh when is that app going to be available for KDE or GNOME. For example, to take something recent here, do the people writing the Zed editor promise a particular DE support - no it's available for "Linux."
As to earlier mentioning distros - for a GUI app, there’s more pain from intra-distro variation than inter-distro, both across configurations and supported versions.
Now the big thing, the even bigger thing is probably native Wayland vs X11, but no one says, oh vendor will you please bring your app to KDE or GNOME, specifically. 99% of the time you are happy if you get anything at all.
So the concept of native on Linux (Desktop Linux) just isn't something usually worth discussing.
Linux is a kernel project, and different distributions are for many purposes best considered to be different OS's. Desktops based on Linux mostly are either GTK or QT, and so the native toolkit depends on the desktop you are using.
Is this too much fragmentation for users on those platforms to realistically expect commercial software to support them natively? Yes, of course, but that doesn't mean there is any confusion about what it would mean to do so.