My initial reaction to this was it's unnecessary, even though it is "more correct". We already use WIN32 and it works fine. However it is, yes, more correct. My biggest concern I think is that we will occasionally forget WIN32 is now _WIN32 and make the mistake of using the former. To that end I've added a checksrc warning category BANNEDPREPROC that checks for banned symbols (eg WIN32) on preprocessor lines.

Good idea to make checksrc check for this.

I'm thinking to sync curl/curl.h with this and replace
CURL_WIN32 with _WIN32, to avoid the minor chance of
it disagreeing with what 'win32' is in the internals and causing
issues.

CURL_WIN32 seems to be a documented feature of curl.h
since 7.69.0, so we might want to keep it around for compatibility,
if we're convinced this is useful or necessary. I tend to think it isn't.

This would be a reboot of 1adebe7
and 8bd863f + #4854 + #4855, but
instead of keeping around CURL_WIN32 as a replacement for our local
WIN32 we just rely on _WIN32, which works universally out of the box.

What do you think?

I struggle to think of when _WIN32 isn't available. Let's see if anyone else has anything to say on it...

Ref: #4855

Some references:

• https://web.archive.org/web/20190205162154/nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system#WindowsCygwinnonPOSIXandMinGW
• https://github.com/cpredef/predef/blob/master/OperatingSystems.md#windows

One list mentions Borland C++, so I made a test with
its 5.5.1 version from 2000, and it does define _WIN32.
I also tried Open Watcom 1.9 from 2010 and it does too.
Pelles C most definitely had it because it was emulating
MSVC in most aspects.

Can't think of more niche compilers that are still around.

But if there are, they can almost certainly set -D_WIN32
manually at build time. Not just for curl.