windows: use built-in _WIN32 macro to detect Windows

[vszakats]

Windows compilers define _WIN32 automatically. Windows SDK headers
or build env defines WIN32, or we have to take care of it. The
agreement seems to be that _WIN32 is the preferred practice here.
Make the source code rely on that to detect we're building for Windows.

Public curl.h was using WIN32, __WIN32__ and CURL_WIN32 for
Windows detection, next to the official _WIN32. After this patch it
only uses _WIN32 for this. Also, make it stop defining CURL_WIN32.

There is a slight chance these break compatibility with Windows
compilers that fail to define _WIN32. I'm not aware of any obsolete
or modern compiler affected, but in case there is one, one possible
solution is to define this macro manually.

grepping for WIN32 remains useful to discover Windows-specific code.

Also:

• extend checksrc to ensure we're not using WIN32 anymore.

• apply minor formatting here and there.

• delete unnecessary checks for !MSDOS when _WIN32 is present.

Closes #12376

[jay]

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.

[vszakats]

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?

[jay]

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

Ref: #4855

[vszakats]

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.

[vszakats]

It's curious that _WIN32 or __WIN32__ could end up together with __SYMBIAN32__,
so that it had to be guarded-out.

Added in 1960eeb (2008). Anyhow, Symbian was deprecated
in curl in 3d64031 (2020), so this no longer a concern.

[vszakats]

Ref: #12378

[dfandrich]

It's curious that _WIN32 or __WIN32__ could end up together with __SYMBIAN32__, so that it had to be guarded-out.

It's been too long for me to recall for certain, but it may have been for x86 builds targeting the Symbian emulator running on Win32.

[bagder]

I'm fine with also removing CURL_WIN32 from the public header. We never documented it for any purpose. It is mentioned in symbols-in-version simply because it is present in curl.h but I don't think we break any promises (API/ABI) by taking it away again.