My first job out of university was in a company that developed a GUI appication based on the Win32 C API. In fact, the product has been on the market for so long, that it's code had been a Win16 application in the past and pre-dated Win 3.1 (It is a product for a niche market, and had been the first Windows program on the market there, with all other software being MS-DOS Applications).
So, I came from university, had written Software during my master thesis with Qt, had some exposure to Gtk on my home PC a few years before, and I faced this obscure Win32 API, which looks ugly, appaling, antiquated and plainly awful.
But: Development was actually quite pleasant, and, while it didn't offer the flexibility of full-blown object oriented libraries like Gtk or Qt, it was amazingly good at getting stuff done. I wouldn't start a new project in it of course and it seems Microsoft has pretty much abandoned the API. But, I have to admit that I can see how it served Microsoft and its developer community well for a few years. In fact, a lot of things in there where quite thoughtful and I can still appreciate the non-bloaty way of doing things, if I see how many processes and memory an electron app uses that doesn't do much more than what a simple Win32 program does.
No they havent. Everything else in Windows land is just built on top of it.
I also made some Win32 development at one point. The programs made using only Win32 have a very snappy and light weight feel to them that is very nice. It is fairly low level and more for the machine than for humans. But I doubt you can have both of these things.
I started with a bit of Win16 and then moved to Win32, and don't really see why it gets a lot of hate; it's not perfect, but it looks like it does exactly what it was meant to do, and does it well. Perhaps it's because all of the tiny and fast applications I've used in the past were pure Win32. You can do a lot with it in only a few KB or tens of KB. In contrast, I don't find all the other multi-megabyte UI frameworks appealing.
> I started with a bit of Win16 and then moved to Win32, and don't really see why it gets a lot of hate; it's not perfect, but it looks like it does exactly what it was meant to do, and does it well.
From a birds' eye view: Because it's just not productive to write apps without some type of modularity, and the WndProc abstraction encourages enormous monster functions that do everything. There's a reason why all UI frameworks have some kind of modular paradigm, whether it's object-oriented or functional reactive or what have you.
More specifically: A lot of the core APIs are just bad. RegisterWindowEx has a struct with a dozen random fields, and CreateWindowEx has a ton of confusing random parameters. For example, why do you have to specify a menu when you're creating a button? Why is dwExStyle the first parameter and dwStyle is the fourth? Why do you have to specify a cursor explicitly instead of just having a function that sets it if you want a non-default one? It's possible to make a low-level C API that's actually reasonably pleasant to use, as in GTK+. Win32 is just a mess.
I have worked with both and i find Gtk+'s C API to be very bad actually, much worse than Win32. Sure, it looks more consistent but that doesn't help when what you want to do is done in a hair-pulling way. It is also much more verbose, though it hides that because it is overall a higher level API than Win32.
The issues you mentioned do exist but they are just minor nitpicks - at the end of the day it doesn't matter at all if the dwExStyle parameter is at the first, fourth or at the last (my guess was that is first to allow for a quick textual search and replace in code to "upgrade" from "CreateWindow(..." to "CreateWindowEx(0, ..."). This is the sort of stuff that will never cause any sort of issue in practice.
Also there are no confusing random parameters in CreateWindow if you actually read the documentation. The menu parameter for a button isn't used for a menu but for an identifier that allows you to distinguish that button from other controls in the window.
Finally your winproc's switch can actually call dedicated functions. You can even write a couple of macros that do that for you so you do something like
Exactly this. As a Windows API/GDI developer, I used to loathe the WndProc way, but after looking at how Qt and Gtk do things, I really really miss it; specially considering the aforementioned libraries requires megabytes of space while a simple winapi program might take a couple dozen kilobytes.
What I dislike about Qt is that it's a C++ only library with no proper way to use it in C. And Gtk imposes a convoluted object oriented C library you should learn and the usual tried & tested RAD point & click to get forms done is way more complicated than it should be, vis a vis the MSVC form builder, the way .NET does it or hell, even VB6. In hindsight, Windows API/GDI was great.
FWIW Windows - or at least the HWND parts - is also an object oriented API, it is just closer to something like Smalltalk (which i guess was more popular at the time) than C++. You still define a class with a message handler on it, create instances of this class and can create subclasses. Windows are really supposed to communicate with the outside world via messages and some Win32 calls are really just wrappers for SendMessage.
GUIs tend to fit perfectly with object oriented systems, so it makes sense for a GUI library for a non-OOP language to need to "invent" one. I think one failing of the Windows API was that they made this only for visual windows instead of creating a more generic "HOBJ" object system with message passing that the GUI bits would be implemented on and other system and user APIs would also be able to use.
Though on the other hand Windows event-driven message passing was already a culture shock to most programmers at the time and this could make things even harder :-P
What I like about Windows API when compared to GTK is exactly that: the OO/class system is kept at a minimum and is limited to the handling of the widget tree.
I don't find any of this persuasive, but I'll just say: If Win32 were actually more ergonomic than modern UI development, then you'd actually see people using it for apps. Instead, Win32 is basically only used for maintenance of legacy apps at least 15 years old and low-level plumbing. Developers want something better.
Most modern frameworks provide more functionality than raw Win32, such as automatic layout management and most of those are also cross-platform. People use those frameworks because of those features and/or need to be cross-platform, not because of Win32's ergonomics.
Win32 only provides the basic building blocks for the UI and Microsoft decided that this is enough (i disagree, i'd like them to add new APIs to Win32 for stuff like layout management, resizable dialogs, dockable panels, etc) and anything else should be provided by other libraries, so you just see people using these other libraries.
Those articles seem overblown. Providing access to UWP APIs from regular desktop apps will, if anything, increase the number of applications using those APIs. UWP GUI APIs could be especially attractive option to those applications currently using win32 forms.
I wonder how exactly will those WinUI (or UWP GUI) APIs will be used in practice though. The vast majority of applications that still use Win32 do it through some sort of framework (be it wxWidgets, MFC, VCL/LCL, etc) that has specific assumptions about what desktop applications are and how they are made. From what i've seen, mixing WinUI and Win32 on the same application kinda feels like dropping a web control in a VB6 application and using HTML+JS to create the UI (which ignores pretty much all the strengths of VB6 while retaining all the limitations).
I have a hard time imagining why anyone who isn't forced to use WinUI in their Win32 application (forced in the sense that some middle manager heard about it and believes it is a good idea so forces the developers to use it) would use it in the first place. I mean, many applications/frameworks do not even use stuff available through COM since Vista and instead prefer to recreate them using the plain C APIs and that is for a seemingly simpler and more understood variety of COM.
> Now in Windows 10, User32/GDI is deprecated and obsolete for high-performance applications (and it’s really slow too after they axed GDI hardware acceleration in Vista), but there isn’t a single replacement, instead there’s like 5 of 6 - all incompatible with each other. While it’s true that it shouldn’t matter because OLE objects were rendered to their own separate hWnd, consider that the new UWP system doesn’t use hWnds, and frameworks like WPF have “air gap” issues with rendering their content overlaying another hWnd and often resort to hacks using window content blitting which drastically hurts performance (as you need to blit to/from RAM, instead of keeping it all in VRAM).
Sort of. It uses Win32's windowing and input/message loop primitives for top-level windows but within a window's content all the layout, controls and rendering are WPF-bespoke. This is different from Windows Forms which wraps Win32 controls. It's also different from UWP/WinUI which can use Win32 windowing primitives, but doesn't necessarily depend on them. This is all using Win32 to refer specifically to the UI side of things, but if we use "Win32" to refer to the entire set of flat C-style Windows APIs then all these frameworks are heavily dependent on Win32
> and I faced this obscure Win32 API, which looks ugly, appalling, antiquated and plainly awful.
As you point out, the code you had to deal with was actually written using the Win16 API.
That Win16 API dates back to the first ever version of Windows which takes you back to a pre 1990 era.
As someone who did work on both Win16 and Win32, what I found amazing is Microsoft designed Win32 such that you could take your Win16 code, do a minimal number of changes and recompile that code for Win32.
That meant you could take your old Win16 code designed for a now obsolete version of Windows, do a minimal number of tweaks, recompile the code using a 32 bit compiler and have it running on the most resent 32 bit versions of Windows.
It was my first experience of a major coding upgrade and it was the last such upgrade that was anywhere near as simple as that upgrade.
32-bit apps running on 64-bit Windows run using a Windows component called "WoW64". There is another compatibility layer used to run 16-bit apps on 32-bit Windows called "WoW".
Neither "WoW64" nor "WoW" are usually referred to as "hypervisors". That term is usually reserved for systems which run a full operating system using CPU virtualisation technology – Hyper-V, VMWare, VirtualBox, Xen, KVM, etc.
By contrast, WoW64 and WoW are rather thin translation layers. WoW64 just intercepts the 32-bit API calls, translates the parameters, invokes the 64-bit API, and then translates the results back to 32-bit. (WoW does basically the same thing for 16-bit calls to 32-bit.) This is possible because all of the Win32 API calls have Win64 equivalents (likewise, most Win16 API calls have Win32 API equivalents, except for a handful of obscure Win16 APIs which newer versions of Windows don't support.)
WoW runs under NTVDM which uses virtual 8086 mode, so you might call WoW a "hypervisor" in that sense (although the hypervisor is really NTVDM not WoW.) But WoW64 does not use any virtualisation technology at all.
WTL is a great attempt at creating a close-to-zero-cost C++ library around the Win32 UI architecture. I use it sometimes even today, and it's not bad considering the age of the foundations.
There are other win32 APIs that are quite interesting:
* the networking API (native proactor servers, something that Linux doesn't have yet AFAIK)
* the security and process API, which I had the pleasure to explore recently, in order to contribute to an open source server that launches a single user server for a connected user, under the user's profile. The CreateProcessAsUser function and its interactions with user authorization tokens is quite something.
I've been playing around with VMS on my MicroVAX 3800 lately, and between that and getting into Windows internals I'm just super fascinated by the difference in feel, when it comes to what the system-level APIs provide, of these highly-integrated, enterprise-oriented operating systems versus the *nix family. Particularly how robust things like user identity management are.
Not saying it's better or worse, of course. Just interesting.
I'd really love to play around with something as hyper-integrated as z/OS or something. So if anyone's got an old ES/9000 or something kicking around that they wouldn't mind sending me, let me know.
Windows via C/C++ is another one in this area. Windows Kernel Programming by Pavel Yosifovich is a recent book, but it goes much lower-level.
Windows Internals is pretty good, but it's not a programming book per se. It's trying to document the design of the OS, help with troubleshooting when you don't have the source to the OS, and help developers understand the high-level concepts.
Programming Windows 5th Edition by Charles Petzold, still commands a price on eBay for its Win32-centric program development strategy. IIRC 6th edition used C# .NET and 7th and 8th went all in on UWP.
Just noticed that the 5th Edition is still available on Kindle (at least on Amazon Australia) and is a lot cheaper than I expected it to be. The hardcover edition is still very expensive there though.
I/O completion ports? Those are great and I wish Linux had a similar API. Epoll doesn't fully solve the asynchronous I/O problem since files always have data available to read. The kernel should be able to do reads and writes in the background while my program does something else.
My favorite Win32 tutorial is by Bartosz Milewski, I found it as a series of posts on his CodeCoop website (https://web.archive.org/web/20110129015721/http://www.codeco... ), that were later incorporated into his book "C++ in Action" (also findable online).
He uses C++ to wrap every resource acquisition in a constructor and every release of a resource in the corresponding destructor, so that by allocating new objects on the stack you avoid a whole swath of memory management errors. This was my first encounter with RAII (not sure if he calls it that), and it seems a particularly elegant way to write C++ and to make the raw Win32 C API a lot less scary.
Windows development team now has an internal C++ library used inside Windows source code to do similar things, which was recently made public and open source on GitHub: https://github.com/Microsoft/wil/wiki
I cut my teeth on making the jump from turbo pascal programs to GUI via the Win32 API. Its "rawness" felt fun, i.e. slinging around "long" pointers to stuff and big event handling switch statement state machines. As long as you didn't misbehave in the message loop, you could just kinda tinker endlessly. As both the UI evolved to many more complicated controls and the toolset was getting more abstract, I'd always find myself asking "dangit! i wish i could just get the UUID for the control that does the fizzywizzybizbang control that i see in Excel here!" Maybe that mindset is akin to a modern UI developer buried in quirksmode.org and their browser console debugger.
I wrote an emulator for an old 8080 microcomputer in 1999 or so using the Win32 API. First I bought the Petzold book, but as my program grew there were still a lot of API issues that Petzold simply couldn't fit into a book of that already impressive size. Then I got a "Win32 API Bible" type of book, then another from a different author, then I collected the multi-volume official win32 api books from microsoft, ..., and ended up with more than two linear feet of books.
And yet development was still painful. Sometimes I would want to add a feature and I'd be amazed that in 30 minutes it was done, but far more often there would be something that didn't work and I'd literally spend two weeks of free time changing the order of state setting calls, or setting state that the books didn't say needed to be set but I had seen other source code do it, reading other program source, searching online, asking in forums...
The last release was in 2005. I'd like to work on it more, but there is no way I'm ever going back to that codebase.
Aaaaah the memory of making the an efficient self extracting archive. What is brilliant about the idea is that even to this very day many "new ideas" live around same event loop idea.
Funny you mention that, but one of the better pieces of MFC related advice I read was to have a single central location for computing UI element states. It did feel a lot like React does these days (albeit with less sophistication in the underlying 'DOM model' back then, and nothing like React's differencing stuff.)
To me at least, if you change the terms in that article, it looks a lot like the arguments in favor of moving away from ad hoc jQuery spaghetti and to React's single global rendering pass.
Ah the Win32 API. Oddly, I learned quite a lot of object oriented fundamentals doing C++ Win32 programming indirectly using Paul DiLascia's excellent book "Windows++"[1]. One of the few 90s era programming books I still have.
Nice! I learned programming using "Iczelion's Win32ASM tutorials" (archived here: http://www.interq.or.jp/chubu/r6/masm32/masm006.html ). Same API, but in assembler. The terminology and variable names look very familiar
Ah, the classic approach from WinProc() upwards. While I think it might be useful to work through this once, since then you understand what a message loop is and how it dispatches to controls, but for almost all practical purposes if you want to build a classic app it's easier to do it in C++ with MFC/ATL. Or even C#/Winforms.
I note this version uses LPSTR rather than LPTSTR; perhaps it predates the UNICODE fiasco and the brief window where UCS-2 seemed like a good idea.
Note that if you decide to use MFC you still need to know Win32. A common misconception and source of frustration about MFC is that it is a layer over Win32 or that it somehow replaces it, which is not the case and if you (royal you here) expect that you'll be disappointed. MFC is a helper framework build with Win32 and C++ to ease some bits of making a Windows application, but even for the most basic stuff you are still dealing with Win32. It isn't a "Win32" or "MFC" situation, it is a "just Win32" or "Win32 and MFC" situation. If you don't like Win32 or feel it is too hard, chances are MFC wont change your opinion either (though you can like Win32 and dislike MFC - after all it has been left to rot).
I have done quite a bit of Win32 in my life and I think even to this day this knowledge helps me diagnose issues with UI performance of browsers and other applications.
I'm not much of a windows user so sorry if it's a dumb question, but don't newer UI libraries like UWP and WinUI just act as wrappers around Win32 functions?
Like if I wrote a UWP/WinUI/etc program and disassembled it, wouldn't it just call Win32 functions in some system dll to do things like create windows, receive messages etc?
Win32 was complicated. Lots of cleanup work. No forced structure. Combine that with having to use C, and the amount of low-skilled porogrammers out there, you could really see why there was so much terrible Windows software out there.
Learning Windows programming gave me so much insight to programs crashing and all the graphical bugs, beause I had caused them all in my own porograms before.
Win32, especially when it comes to GUI programming, is one of the worst APIs out there.
MFC is also quite bad because of huge abstraction leakages; it fills like Win32 with bolted on classes.
It seems like Win32 happened a bit by accident, a bit by overengineering and a bit by Microsoft's attempt to lock everyone to their 'special' development environments, which did not include C as a conscious choice by Microsoft.
> Win32, especially when it comes to GUI programming, is one of the worst APIs out there.
It's also one of the first. Win32's origins extend back over 35 years and start on machines with a tiny fraction of the capability of even the smallest of today's modern PC's. It was also built with a different set of tradeoffs and in a radically different culture of software development. (Most modern developers hadn't been born at the time of it's initial design, and most of the people who were actively writing this stuff in the early-to-mid 1980's, I'm sure have moved on. 35 years is pretty much a career.)
> MFC is also quite bad because of huge abstraction leakages; it fills like Win32 with bolted on classes.
That's pretty much what it was... by design. There was a more object-oriented library that Microsoft developed, prior to MFC. They tested it on developers that had essentially just come up to speed on the (then-new) Win16 API, who all complained about having to ascend another learning curve for a fancy object oriented language and framework. Microsoft's reaction was to drop the older framework (referred to as AFX) and develop MFC as a thin wrapper around Win16. (This is part of why there are AFX prefixes scattered throughout the MFC codebase.... it's a legacy of the earlier framework.)
Even then, early versions of MFC had some utility, mainly around making things more type safe. Because it bound C++ instances to Window system instances, it made it easy to attach user data structures to UI components. (Otherwise, you were worrying about window or class words, which were Microsoft's original approach to that problem and used by MFC under the hood.) MFC also handled parsing of window message arguments. Win16 also sent messages with just a word and a long, when what you really might need is a set of mouse button flags and an x/y position or something. MFC helped with that too, by 'cracking' the message arguments into something closer to what you'd expect.
(To this day, Win32 documentation still includes instructions on parsing WPARAMS, etc.
MFC was built for a reason. To provide that doc/view/OLE GUI. If you wander too far away from that it becomes well, lets just say, 'interesting' to use. I would many times just include MFC just to get some of those helper classes though. CString was way ahead of the game. C++ did not get a std::string standard that most people could use until well into the 2000s. Its database classes were good in a pinch to abstract away the nitpicky junk in ODBC. Then C++ took a 15 year sideways journey into getting templates right. During that time MS created C# and basically took away any reasons to really use MFC and C++ on windows for business applications.
I did some MFC for my job and disliked it. It didn't help that the software in my job was made up of thousands and thousands of COM objects and everything felt like treacle to write (got to implement those interface functions I'm never going to use!).
I have used wxWidgets a lot and really like it, but for modern C++ on Windows what do Microsoft recommend?
I can't seem to get any idea. Honestly, I would like to know.
COM was not really well designed to be consumed from C++ that is why it felt horrible to you. It was designed for visual basic and Office. If I never see another VARIANT I will be soooo happy. ATL made COM better to use but not much. In visual basic a COM object was dead easy to make and manage. In C++ it came with a bunch of baggage of extra API's to fiddle with and no real clear direction how/why to do so.
I do not know what MS would recommend these days. From my point of view they basically functionally abandoned it but dragged it along because most of their stuff was built with it. The .NET libs was where all the new stuff was going (WPF, WinUI). WTL may be worth a look it looks like it comes out of the ATL/MFC lineage.
It's kind of interesting, when you compare WinAPI to classic Mac Toolbox, how incredibly similar their core concepts are.
Especially when you take into account that the first GUI application MS made was Excel for the Macintosh. And then they more-or-less wrote Windows as a runtime environment for porting Excel to PCs.
Not getting into any of that old-school MS-stole-the-GUI flamewar business, I just think it's genuinely historically interesting to note the parallels when you play with each.
A big difference is that Windows used inversion of control. You give the system a callback and it calls you with an event. The Mac toolbox was written with the idea that each application had full control of the machine. This made multiprogramming ... interesting. On the Mac, for example, when you pressed down on a button, it would go into a mode where the button’s code would take all the events until the mouseUp event.
> You give the system a callback and it calls you with an event
Maybe I haven't done enough WinAPI programming, but where is that true? I know there are a few helper functions that automatically dispatch an event to a callback, but I thought in general all events had to be intercepted and dispatched in the message loop
Yes but windows calls your event loop directly for WM_PAINT as well as the event loop calling a system function that calls your window procedure, again investing control. On the Mac you used to hit test the event yourself and figure out which window it was meant for.
The design of Win32 is incredibly close to the design of Win16 and since Win16 dates back to early 90's you need to comparing it to GUI programming layers of that same era.
So the question is, back then was there any better GUI programming layers?
And the answer is yes, there was actually an API that was better and it was called OS/2.
At that time Microsoft was in a partnership with IBM to develop OS/2.
However, when the partnership fell apart, Microsoft just took big chunks of that OS/2 API and created a sub par version and called it the Windows API.
> However, when the partnership fell apart, Microsoft just took big chunks of that OS/2 API and created a sub par version and called it the Windows API.
Microsoft learned from the mistakes IBM forced on them and did a better job. Right off the top of my head:
* IBM forced 80286 compatibility in an 80386 world.
* IBM forced incompatibility between Windows and OS/2 for the sake of preserving their mainframe graphics API's.
* OS/2 had a single messaging queue for the whole desktop.
* OS/2 was tied to the underlying hardware to the extent of being written partly in assembler.
OS/2 was great... I loved OS/2 2.0 in particular (and I worked for IBM testing OS/2 LAN Server for a summer)... but IBM had no idea how to address the market and no sense of how fast it was evolving.
Sort of. IBM really wanted to ensure that OS/2 had an imaging model that was compatible with what it used in some of its larger computers. This resulted in a bunch of differences between OS/2's imaging model and GDI. (Different window origin coordinates, etc.)
In a more Microsoft-centric world, I'm pretty sure the OS/2 API would've been exactly as you describe it and almost strictly in parallel with Windows. In fact, Microsoft did exactly this with Win32s (and Windows 95) In their relationship with Windows NT (which was once known as OS/2 NT or OS/2 3.0).
The same compiled binary could run on both the 'entry level' OS and the 'server level' OS, with a bit of care taken in the way the API was used.
Once Microsoft agreed to the graphics api change, it was open season to redesign the window manager api because backward compat was moot at that point. The OS/2 window manager api was designed by the same team who designed the win16 window manager apis. There were improvements and a bunch of api change but at the 10K foot level the model was the same - input loop, window messages, and window procs.
> at the 10K foot level the model was the same - input loop, window messages, and window procs.
That's a fairly broad description, isn't it? At least I have a hard time coming up with windowing API models that don't fundamentally work that way at the lower levels. (About the only exception think of is a text-based library that shipped with Microsoft BASIC 7.0, and that was mainly because the language didn't support any of the abstractions needed for callbacks.)
That's a fair point, I'll restate: the level of abstraction that developers were exposed to was 95% the same. Exposed message loops, window classes, window messages, unpacking window params, post and send message semantics, painting, single cooperative input queue (window app hanging would hang all apps), and other equivalences.
The Win is just one layer in the OS/2 API and suspect you might be right in that this layer was probably modeled on early Windows.
However OS/2 had many other layers to it's programming SDK that were not found in early Windows.
For example there was the Dos layer for things like processes, threads, semaphores, files, directories etc.
And then there was the Gdi layer for graphics.
Most of that functionality only made it's way into Windows with the advent of Windows NT (Windows 3.x/95 had poorer versions of those functions. For example running a process and capturing it's output was a real pain in Windows 3.x and Windows 95).
And based on the fact so many of those OS/2 Dos function have an equivalent Windows NT version I suspect Microsoft used that OS/2 design as their starting point for NT.
As just one of many examples consider DosCreateThread from OS/2 1.x
Right, this is why i explicitly said "the OS/2 GUI (Presentation Manager) API" and not the entirety of OS/2. The original comment mentioned "was there any better GUI programming layers" after all.
> It seems like Win32 happened a bit by accident, a bit by overengineering and a bit by Microsoft's attempt to lock everyone to their 'special' development environments, which did not include C as a conscious choice by Microsoft.
Maybe I just haven't had my coffee yet, but I'm not understanding what this is supposed to mean.
I don't understand this either. They've always offered C. In many ways Win32 and NT are as much a ""C operating system"" as UNIX. The only "special development environment" might be Visual Basic.
Maybe they meant Microsoft didn't really stick to the C standard library. _strdup vs strdup. malloc vs HeapAlloc. assert, fopen, etc. The functions mostly exist but really aren't the way to program Windows.
After the p-machine era, MS was all in on C. They had some technical reason for preferring the pascal calling convention, like saving a few bytes of program text.
Why on earth would anyone want to learn Win32 in 2019? It's horribly unproductive.
I've been doing Win32 (also called "Petzold-style") since 1995, and am pleased to say I'm converting to Qt for multi-platform capability.
When I look at the dreck necessary to create a dialog box in Win32, and compare to more modern frameworks, it's like milking a cow vs. buying milk at the store. Sure, you're "into the fundamentals", but is that really how you want to spend your time?
The Win32 API is on life-support. Microsoft will maintain backwards compatibility for legacy apps of course, but learning Win32 for new development doesn't seem like a good investment (unless, of course, you want to get a job maintaining a legacy Win32 app).
Anything that runs on the Windows desktop uses Win32 at some point in its stack. If you work on anything that is close to Win32 then you may also need to work with Win32 itself.
For example if you work on a game engine or toolset then you must know Win32 - especially if you work on the tools, even if you are using a wrapper like wxWidgets or Qt.
The only time where you can avoid Win32 is if you're using something that completely abstracts away the entire system, like Java Swing or a web browser.
It's a little bit more complicated. Sure, if you're doing low-level programming I imagine you might run into the Win32 API, but if you're just building typical desktop applications (particularly for newer devices like the Surface Pro X or Surface Neo), you'll most likely want to use UWP. Usage of Win32 for app development is only going to decrease overtime for typical consumer applications. I'm sure businesses will continue building LOB apps in WPF and WinForms until the heat-death of the universe, but there's also businesses building apps in VB6 and you don't see many people recommending to learn that.
Because sometimes it's nice not to have to drag in a large dependency such as Qt. For example PuTTY.exe is only around 500kb and that's all there is to it.
Sometimes, when working on higher-level code, you have to dig into the plumbing layer. For example, I've been writing low-level GPU surface code lately, since SDL and the like are not suitable for our use case (web browsers). There's no getting around message loops and HWNDs if you want to put something on the screen. So it's useful to know the internals, even if you'd never want to write an app that way.
So, I came from university, had written Software during my master thesis with Qt, had some exposure to Gtk on my home PC a few years before, and I faced this obscure Win32 API, which looks ugly, appaling, antiquated and plainly awful.
But: Development was actually quite pleasant, and, while it didn't offer the flexibility of full-blown object oriented libraries like Gtk or Qt, it was amazingly good at getting stuff done. I wouldn't start a new project in it of course and it seems Microsoft has pretty much abandoned the API. But, I have to admit that I can see how it served Microsoft and its developer community well for a few years. In fact, a lot of things in there where quite thoughtful and I can still appreciate the non-bloaty way of doing things, if I see how many processes and memory an electron app uses that doesn't do much more than what a simple Win32 program does.