> 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.
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.