Once you get your head around the basics, is not too hard. Msdn is an excellent resource once you reach that level. One issue that might come to bite you in the ass is all the #defines.

For example, if you make a member function named "CreateWindow", it will actually end up being named CreateWindowW or CreateWindowA if you include windows.h.

Unicode in Windows is utf16, which brings a potential of obscure bugs if you fail to consider surrogate paid (aka emojis will fuck up your sit)

Win32 is about a million years old and is not how Windows application development is done nowadays. So I've got two answers for you depending on why you want to go back to Win32.

1) If you have a specific reason to use Win32 (ie. you specifically want to target Windows 95 for some reason): Win32 is easy to access from C++, you can just call the API functions directly. Back in the day I started out with a book (Sams Teach Yourself Windows 95 Programming or something like that) and from there just figured it out from the API documentation, Win32 is pretty straightforward once you get your head around message loops, handles, events etc. and the documentation is great.

2) I know you said you're not interested in learning something else, but Win32 isn't going to be around much longer and unless you want to be stuck in the past like those Amiga guys, it's worth trying something newer. These days I use wxWidgets for my Windows development, it's a (very well designed IMO) C++ library which started out as a wrapper for the Win32 API and so will be familiar to you from the start, and it's just nicer than raw Win32. Kind of like what MFC should have been. Plus you get cross-platform capability and future-proofing for free.

C is a subset of C++. You're fine there.

But what exactly do you want to accomplish? Win32 is mostly a tool and one who's functionality is now taken care of automatically in most modern IDEs. I programmed in Win32 for years and couldn't even begin to write the basic code for just having a simple window on screen. It's full of strange conventions, variable names like lpfnWndProc, and borderline arbitrary typedefs of typedefs of typedefs like WPARAM and LPARAM (don't you dare mix up the purpose of those two highly descriptive type names either!) enough to leave you having no idea the types you're dealing with. And in fact in many cases it's okay to have no idea as there will be parameters and other things that literally are just no longer used.

The entire API dates back to 16bit days. Instead of rewriting it as technology changed they just kept patching and adding onto it which in part is why it's so poorly designed. I think it could still be a good exercise in learning how an event driven messaging system works under the hood, but the entire API is a pitfall. Even when you know what you're doing you'll be spending 80% of your time on MSDN and 20% writing code. I would recommend free online tutorials over books in this case. There's always lots of little gotchas in things like this when developing direct Win32 on modern OS's on modern hardware. Types change, those variables that are no longer used were used at one time, and so on. Good luck!

It is not clear what you want to do. But I assume you want to create dll's?

If you have Visual Studio and create a C/C++ application then you are basically already in Win32/64