@MarcelRaad and @jay thoughts?

Everything curl is now correspondingly mentioning the "generate with cmake" way: https://everything.curl.dev/build/windows.html

The documentation needs to be updated. Also I would include the generated VC10-12 with the tarball if the tarball can still be reproducible. I forgot we stopped doing that.

I would include the generated VC10-12 with the tarball

nm. I removed the dead code for VC14 and changed the README to explain that generate.bat must be run to generate the legacy versions of Visual Studio project files and cmake must be run to generate later versions of Visual Studio project files.

Ah yes, appveyor uses generate.bat for the VS2017 build so we either need to keep support for that, or switch to generating the project files with cmake there...

Ah yes, appveyor uses generate.bat for the VS2017 build so we either need to keep support for that, or switch to generating the project files with cmake there...

Strong vote for the latter. It would also serve as an example for how to do that.

The only reason I used Visual Studio 2017 for that build in #3941 is that it was the latest version for which Visual Studio solution files existed back then. Not sure if switching it to CMake would make much sense as we already have a lot of CMake builds. I'd rather switch it to VS 2013, which is also the oldest version supported by Appveyor. Otherwise, we have no Visual Studio solution build at all in CI, right?

Or did I misunderstand something and the plan was to turn it into something special?

An option to keep this job useful is moving it to VC 12 (= Visual Studio 2013) (from 14.10 aka Visual Studio 2017). This compiler version isn't tested at the moment and generate.bat continues to support it. It's available in the "Visual Studio 2015" AppVeyor image: https://www.appveyor.com/docs/windows-images-software/#visual-studio-2013

Here's a translation table for the confusing MSVC version numbering schemes:

Compiler                                _MSC_VER value
--------                                --------------
C Compiler version 6.0                  600
C/C++ compiler version 7.0              700
Visual C++, Windows, version 1.0        800
Visual C++, 32-bit, version 1.0         800
Visual C++, Windows, version 2.0        900
Visual C++, 32-bit, version 2.x         900
Visual C++, 32-bit, version 4.0         1000
Visual C++, 32-bit, version 5.0         1100
Visual C++, 32-bit, version 6.0         1200
Visual Studio .NET (2002), version 7.0  1300
Visual Studio .NET 2003, version 7.1    1310
Visual Studio 2005, version 8.0         1400
Visual Studio 2008, version 9.0         1500
Visual Studio 2010, version 10.0        1600
Visual Studio 2012, version 11.0        1700
Visual Studio 2013, version 12.0        1800
Visual Studio 2015, version 14.0        1900
Visual Studio 2017, version 14.1*       1910-1919
Visual Studio 2019, version 14.2*       1920-1929
Visual Studio 2022, version 14.3*       1930-19??

Tested the VC12 approach here, with success:
https://ci.appveyor.com/project/curlorg/curl/builds/49581291/job/427yrxk4qmquqvv2

Patch:

--- a/appveyor.yml
+++ b/appveyor.yml
@@ -230,12 +230,12 @@ environment:
       TESTING: 'OFF'
       ENABLE_UNICODE: 'yes'
     # generated VisualStudioSolution-based builds
-    - job_name: 'VisualStudioSolution, VS2017, Debug, x86, Schannel, Build-only'
-      APPVEYOR_BUILD_WORKER_IMAGE: 'Visual Studio 2017'
+    - job_name: 'VisualStudioSolution, VS2013, Debug, x86, Schannel, Build-only'
+      APPVEYOR_BUILD_WORKER_IMAGE: 'Visual Studio 2015'
       BUILD_SYSTEM: VisualStudioSolution
       PRJ_CFG: 'DLL Debug - DLL Windows SSPI - DLL WinIDN'
       TESTING: 'OFF'
-      VC_VERSION: VC14.10
+      VC_VERSION: VC12
     # autotools-based builds (NOT mingw cross-compiling, but msys2 native)
     - job_name: 'autotools, msys2, Debug, x86_64, no Proxy, no SSL'
       APPVEYOR_BUILD_WORKER_IMAGE: 'Visual Studio 2017'

Thanks a lot @jay and @vszakats !