I help maintain an active win32 MFC program. MFC/32 is astonishingly still very much alive, and will be for some time. But learning legacy tools just because someone out there maintains code in them is not time well spent unless you know you will be doing exactly that.
When I was first learning Windows programming it was Win32 and Windows 98 all the way. "The Bible" was "Programming Windows, Fifth Edition" by Charles Petzold.
The 6th edition of his book was .NET and C# for Win 8/8.1.
The API (Application Programming Interface) for Windows apps is HUGE. Frameworks such as .NET or MFC try to hide all the nitty-gritty details.
If you want to learn Windows programming you should use Visual Studio. Yes, the bugger is HUGE, eating up a lot of HD space. But Windows IS MS, so why not use the IDE MS has. Tight integration and a decent debugger when needed.
VS 2019 is the current version, 2022 is still in preview status.
If having the best C++ standard compliance getting 2022 when it goes into full release status would be the thing to do. 2019 is 100% compliant now, but any C++20 defect fixes won't be patched in.
Some say winapi is legacy and it should no longer be learned because of modern ready and easy to use toolkits but I think the truth is opposite...
libraries such as MFC or Qt are legacy, these were first developed some 20 years ago, the code is vintage and upgrade to recent standard is likely not possible.
some say learning win32 is not productive because writing programs takes significantly more time which is ignorant statement because nobody would write always from scratch..
If you write class Window, class Button, class this and class that then reusing these classes is become productive on it's own.
Another major benefit is you can update and adjust your code when ever something doesn't work or whenever you want something to look differently or work better.
If you want UI library to be native and standard compliant and have all the flexibility then win32 is the only choice because none of the current libraries will offer you freedom to do it your own way.
What I wanted to say is that MFC, Qt and UI libraries in general are libraries that even though still updated go out of date by design, a design whose change is not possible.
This is to ensure full employment for programmers. Where I used to work we had a mission critical application built by an outside contractor where a Windows Class Framework was utilized. Every couple years the class framework was updated so we had to spend another couple hundred thousand dollars every couple years to upgrade to the new version (it was a multi-million dollar class application). Of course, every version became more bloated and slower with dependencies and so forth, so we had to buy more powerful hardware to run the application. All kinds of money involved. Good for programmers, Good for hardware manufacturers, so on and so forth. It's what makes the world go round.
Eventually I coded the whole application Win32 Api SDK style using PowerBASIC. Eventually the creator of the PowerBASIC programming language passed away and for a backup I recoded the entire thing in C++ (C++ will outlive Bjarne Stroustrup). The C++ version I still have for a backup if ever needed, but it has never been needed. The organization is still running my PowewrBASIC 32 bit executable (this has been going on for like 20 years now).
This was an application (not mine - the original) that an army of coders worked on for several years. At best it only ever half worked. Sound familiar? When I recoded it in PowerBASIC Win32 SDK style there were two seperate executables involved which came to about 1200K, however they each compressed to around 175k or so. These were stand alone executables requiring no run time dependencies other than a 32 bit Windows Operating System. No installation was ever needed; users could stick the executables on a server and pull them across the wire, or run them local.
My C++ versions were even a bit smaller than the PowerBASIC versions but to accomplish that I used my own custom C Runtime and my own classes (nothing from C++ Standard Library - too much bloat there under Windows).
I've really no recommendations for the original poster. I'm astounded Microsoft still allows Win32 SDK code to work. I guess for various technical reasons known only to them they have to. I guess if I were just starting out now even I would have to go the class framework route. One has to do what one has to do to survive.
WinAPI is an umbrella term for various APIs available for the multiple Windows versions, a catch-all for previous and future API versions. The name change reflects its roots in 16-bit Windows, through 32-bit Windows and onto 64-bit Windows.
Win32 was specific to Windows for 32-bit architecture machines, with some slurp over to 64-bit since 64-bit Windows can run 32- and 64-bit apps.
My comment was about future versions of Windows no longer natively supporting 32-bit apps, much the same as current Windows, Win10, doesn't really support 16-bit apps natively. With a 3rd party framework and some rejigging of Windows it is possible. Easier if the OS is 32-bit than 64-bit.
Well, in a nutshell (and very much IMO) the now booted closed account user complained from the get-go that CPlusPlus wasn't a resource that was up to his standards of free information, being years out of date. Demanded the site owner cater to his whims and wants.
The closed account posts were pretty much in the vein of "WinAPI is dead because I say so."
Nothing to lose sleep over, really. I like reading the differing opinions of others, even if happen to believe one side or the other. As long as it is a discussion and civil.