Minimum required Visual Studio version #15972

vszakats · 2025-01-12T02:10:33Z

vszakats
Jan 12, 2025
Maintainer

Would it be a good idea to define it?
If so, what would be a reasonable cutoff version?

Some considerations:

curl's winbuild README says it requires at least Visual C++, 32-bit, version 6.0 (1998).
curl's Visual Studio Project files support VS2010, VS2012, VS2013.
CMake dropped Visual Studio Project file generation for VS2010, VS2012, VS2013 in autumn/winter 2022, 2023, 2024, respectively. Now requires v3.24 or older to target them, or latest versions with VS2015 installed.
Windows CE used to require VS2008, but VS2015 should also work. (I haven't tried them)
VS2003 was the last version supporting Win95. Somebody managed to build a recent curl with it: https://datagirl.xyz/posts/wolfssl_curl_w2k.html (some of the issues revealed in the post are since fixed)
(Note that mingw-w64 is more liberal in targeting old OS versions.)
VS2003 is the oldest known version capable of building curl. (based on the article above). VS2002 is similar, and might work too.
VS2005 is required for large file support (for _fseeki64()). It's the last version supporting single-threaded CRT. The first version supporting x86_64.
VS2008 is the oldest one we can build in CI (AppVeyor). Some build combinations (shared+debug) do not work [edit: being fixed in cmake: pre-fill known type sizes for Windows + and more #16394 → windows: drop code and curl manifest targeting W2K and older #16453].
VS2010 is the first version supporting C99 stdint.h.
VS2010 is the oldest one we actually build in CI.
VS2010 -DCURL_DROP_UNUSED=ON (with CMake builds) not doing much, even though the options are documented and accepted.
VS2012 is the oldest release where /OPT:REF (via -DCURL_DROP_UNUSED=ON) reduce binary size. Ref: 66ad54e cmake: add CURL_DROP_UNUSED option to reduce binary sizes #20357
VS2013 allows dropping most MSVC-specific workarounds in curl. Has inttypes.h.
VS2015 is the first to use UCRT (Universal CRT). Also the oldest version with online documentation. (Meaning: anything older disappeared from the official online documentation.)
VS2015 and 2017 are slow to configure/generate with CMake on AppVeyor CI.
VS2015 okay-ish C99 support.
VS2015 is the latest version supporting Window CE.
VS2017 allows dropping all MSVC-specific workarounds in curl.
VS2019 is the first version supporting ARM64.
curl requires 64-bit types (aka _INTEGRAL_MAX_BITS >= 64). Those are known to be available in VS2003. Maybe also in VS2002, and Visual C++ 6 (1998).
VS2026 64-bit only.

C99 support details: https://learn.microsoft.com/cpp/overview/visual-cpp-language-conformance#c-standard-library-features-1

IMO:
It'd be useful to document it and align to it throughout the code and builds.
Anything older than VS2003 can be dropped without concern.
Requiring at least VS2008 would be nice. (It makes Win95 builds require MinGW, which is fine). We can test it in CI if necessary.
Requiring VS2010 would be even nicer, allowing C99. (but may disturb some Windows CE users). We do test it in CI.
VS2013 would be a plus, but may be too early.

This may also make a useful survey question.

curl code with special handling for pre-VS2010 versions:

lib/strtoofft.c:#     if defined(_MSC_VER) && (_MSC_VER >= 1300)                             -> VS2002
lib/config-win32.h:#if  (defined(_MSC_VER) && (_MSC_VER >= 1310)) || defined(__MINGW32__)    -> VS2003
lib/config-win32.h:#if  (defined(_MSC_VER) && (_MSC_VER >= 1400)) || defined(__MINGW32__)    -> VS2005
lib/config-win32.h:#if  (defined(_MSC_VER) && (_MSC_VER >= 1400)) || defined(__MINGW32__)    -> VS2005
lib/config-win32ce.h:#if defined(_MSC_VER) && (_MSC_VER >= 1400)                             -> VS2005
lib/curl_setup.h:#if     defined(_MSC_VER) &&  _MSC_VER <= 1400  /* !_MT */                  -> VS2005
CMakeLists.txt:  if(NOT MSVC OR (MSVC_VERSION GREATER_EQUAL 1400))                           -> VS2005
lib/config-win32.h:#if   defined(_MSC_VER) && (_MSC_VER >= 1500) && (_MSC_VER <= 1600)       -> VS2008
CMakeLists.txt:  if(CMAKE_C_COMPILER_ID STREQUAL "MSVC" AND MSVC_VERSION GREATER_EQUAL 1500) -> VS2008

MS compiler names/versions/years:

Name	`_MSC_VER`
C Compiler version 6.0 (1989)	600
C/C++ compiler version 7.0 (1992)	700
Visual C++, Windows, version 1.0 (1993)	800
Visual C++, 32-bit, version 1.0 (1993)	800
Visual C++, Windows, version 2.0 (1994)	900
Visual C++, 32-bit, version 2.x (1994)	900
Visual C++, 32-bit, version 4.0 (1995)	1000
Visual C++, 32-bit, version 5.0 (1997)	1100
Visual C++, 32-bit, version 6.0 (1998)	1200
Visual Studio .NET, version 7.0 (2002)	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 15.0	1910-1919
Visual Studio 2019, version 16.0	1920-1929
Visual Studio 2022, version 17.0	1930-194?
Visual Studio 2026, version 18.0	1950-
clang-cl	19??

https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering
https://en.wikipedia.org/wiki/Visual_Studio

jay · 2025-01-12T03:26:50Z

jay
Jan 12, 2025
Maintainer

Windows CE used to require VS2008, but VS2015 should also work. (I haven't tried them)

I suspect there's more to this than we understand. There's Windows CE 4.0 - 6.0 which AFAICT to target those embedded systems requires Visual Studio 2008 or earlier. If that's what users are using to build libcurl for Windows CE then I think we should continue to support it. I think winbuild is the last build method to allow VS2008.

VS2010 is the first version supporting C99 stdint.h.

Note though VS2010 has that C99 file its compiler is not fully C99 compliant, like for example it doesn't allow mixed declarations in C files but allows them in C++ files.

3 replies

vszakats Jan 12, 2025
Maintainer Author

Windows CE used to require VS2008, but VS2015 should also work. (I haven't tried them)

I suspect there's more to this than we understand. There's Windows CE 4.0 - 6.0 which AFAICT to target those embedded systems requires Visual Studio 2008 or earlier. If that's what users are using to build libcurl for Windows CE then I think we should continue to support it. I think winbuild is the last build method to allow VS2008.

VS2008 builds with CMake just fine. It was running in CI till earlier this
week. Here's a recent log: https://ci.appveyor.com/project/curlorg/curl/builds/51279317/job/5qb41eakmmaf0ohs
It was a time-sink to fix its weird quirks, and has been partly broken, for
a long time. Also no CE support in CI.

If we choose to focus on supporting WinCE with ancient MSVC versions
it will be a blocker for deprecating anything, basically forever. Given the
state and limited use of WinCE, this is a high price to pay.

It'd be useful to know more about the VS2015 build method, also as the
official way to do it now.

CeGCC is also there to fill any gaps.

VS2010 is the first version supporting C99 stdint.h.

Note though VS2010 has that C99 file its compiler is not fully C99 compliant, like for example it doesn't allow mixed declarations in C files but allows them in C++ files.

We don't need full compliance, for now. If we ever do, it might
become a reason to prefer newer VS versions.

jay Jan 12, 2025
Maintainer

Check this out https://building.enlyze.com/posts/a-new-windows-ce-x86-compiler-in-2024/

vszakats Jan 13, 2025
Maintainer Author

Check this out https://building.enlyze.com/posts/a-new-windows-ce-x86-compiler-in-2024/

Nice! It's CeGCC with GCC 9. It would allow dropping a couple of old-gcc workarounds in #15975.
Docker makes it possible to use in CI in theory; in practice I prefer a binary download, and either
will need effort.

CeGCC is very nice. The warts experienced are vastly rooted from WinCE itself, not the toolchain.

It builds cleanly now (with default, basic options), with both autotools and cmake, also in CI.
Some workarounds may break functionality, esp. in curl.exe, but I'm not sure there is
a way to run a command-line tool on WinCE at all. It think it fits the job of build testing
this platform, and better support can be taken from there.

MarcelRaad · 2025-01-12T21:40:36Z

MarcelRaad
Jan 12, 2025
Collaborator

I'd vote for VS 2008, maybe asking on the mailing list for objections first. Having something CI-testable as an official minimum would be good, it still supports targeting Windows 2000, and it's the oldest version we know people are using not just for the fun of using ancient versions.

0 replies

vszakats · 2025-01-13T19:08:15Z

vszakats
Jan 13, 2025
Maintainer Author

Opened #15992

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Minimum required Visual Studio version #15972

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 3 comments 3 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

Minimum required Visual Studio version #15972

Uh oh!

Uh oh!

vszakats Jan 12, 2025 Maintainer

Replies: 3 comments · 3 replies

Uh oh!

jay Jan 12, 2025 Maintainer

Uh oh!

Uh oh!

vszakats Jan 12, 2025 Maintainer Author

Uh oh!

jay Jan 12, 2025 Maintainer

Uh oh!

vszakats Jan 13, 2025 Maintainer Author

Uh oh!

MarcelRaad Jan 12, 2025 Collaborator

Uh oh!

vszakats Jan 13, 2025 Maintainer Author

vszakats
Jan 12, 2025
Maintainer

Replies: 3 comments 3 replies

jay
Jan 12, 2025
Maintainer

vszakats Jan 12, 2025
Maintainer Author

jay Jan 12, 2025
Maintainer

vszakats Jan 13, 2025
Maintainer Author

MarcelRaad
Jan 12, 2025
Collaborator

vszakats
Jan 13, 2025
Maintainer Author