build: require Windows XP or newer#12225
Conversation
After this patch we assume availability of `getaddrinfo` and `freeaddrinfo`, first introduced in Windows XP. TODO: assume these also in autotools. Ref: curl#12221 (comment) Closes #xxxxx
|
I think this is reasonable but here is some context. There is some version of Windows CE that was still supported by MS until earlier this month. curl survey says for the lesser used versions of Windows (page 11) that they are hardly used:
The sample size at 600+ is not definitive but is useful. Note the respondents may have selected multiple versions. I suspect anyone using very old versions of Windows is probably using very old versions of curl, just because we don't get reports for anything older than XP. I wonder how many of those users are using a curl from 5 years ago because everything "just works". For next year's survey I think it would be good to ask which version of curl the user is using. curl 8, curl 7, both, the latest, multiple versions, etc. maybe for those who build how often they build as well (I may have overlooked this if it's there already). There's a similar suggestion in the survey "How often do you update cURL and how do you receive updates?". @bagder |
|
@jay excellent suggestions. I have recorded these notes now, let's just make sure they are remembered when the user survey time comes again. |
bagder
left a comment
bagder
left a comment
There was a problem hiding this comment.
I'm fine with bumping the Windows requirement to XP.
|
Not directly related, but, may I ask if curl intends to support Windows CE? [ esp. in the light that it has been deprecated by MS as @jay mentioned. Code has references to it, but it's rarely if ever mentioned. ] |
|
Merged. I'd be interesed in the Window CE support status regardless! Also this leaves a pending TODO for autotools, where we might also avoid detecting these features for Windows and assume them. |
AFAICT we don't have a standard build process for it. My guess is it's embedded device manufacturers that use it and don't contribute back. Maybe they build it using Visual Studio 2008 and winbuild? It appears possible to build OpenSSL and wolfSSL (at least in 2019) for Windows CE as well. The problem is we don't know how it's being done, if it's even still being done or what to support. |
|
Thanks @jay! |
curl requires Windows XP since 2023. Drop version detection code using `GetVersionEx()` aimed to support earlier Windows versions. With that call deleted, the embedded manifest in `curl.rc` becomes unnecessary. Delete it too, along with the enabler logic in build systems. This allows to stop forcing `/MANIFEST:NO` for MSVC builds. Dropping it fixes VS2008 shared builds, that require an auto-generated SxS manifest to find their CRT DLLs. This was the issue that prevented VS2008 `curl.exe` launching on AppVeyor CI. FWIW the `curl.rc` embedded manifest wasn't ever enabled for VS2008 CI builds either, because CMake did not pass our custom macro via `CMAKE_RC_FLAGS` to `rc.exe`. For reasons I couldn't figure out. After this patch the curl build no longer inject its own manifest, and lets the default be applied by linkers and toolchains. It fixes VS2008 shared builds. curl continues to detect the real Windows version via `RtlVerifyVersionInfo` from `ntdll`. Follow-up to 960d601 curl#12225 Follow-up to 5044909 curl#7810 Follow-up to ebd2132 curl#1221 Cherry-picked from curl#16394
curl requires Windows XP since 2023. Drop version detection code using `GetVersionEx()` aimed to support earlier Windows versions. With that call deleted, the embedded manifest in `curl.rc` becomes unnecessary. Delete it too, along with the enabler logic in build systems. This allows to stop forcing `/MANIFEST:NO` for MSVC builds. Dropping it fixes VS2008 shared builds, that require an auto-generated SxS (side-by-side assembly) manifest to find their CRT DLLs. This was the issue that prevented VS2008 `curl.exe` launching on AppVeyor CI: ``` src/curl.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory ``` Ref: https://ci.appveyor.com/project/curlorg/curl/builds/51577006/job/eitypvwlb1rxr11d#L261 FWIW the `curl.rc` embedded manifest wasn't ever enabled for VS2008 CI builds either, because CMake did not pass our custom macro via `CMAKE_RC_FLAGS` to `rc.exe`. For reasons I could not figure out. After this patch the curl build no longer inject its own manifest, and lets the default be applied by linkers and toolchains. It fixes VS2008 shared builds. curl continues to detect the real Windows version via `RtlVerifyVersionInfo()` from `ntdll`. Follow-up to 960d601 #12225 Follow-up to 5044909 #7810 Follow-up to ebd2132 #1221 Ref: #15972 Cherry-picked from #16394 Closes #16453
curl requires Windows XP since 2023. Drop version detection code using `GetVersionEx()` aimed to support earlier Windows versions. With that call deleted, the embedded manifest in `curl.rc` becomes unnecessary. Delete it too, along with the enabler logic in build systems. This allows to stop forcing `/MANIFEST:NO` for MSVC builds. Dropping it fixes VS2008 shared builds, that require an auto-generated SxS (side-by-side assembly) manifest to find their CRT DLLs. This was the issue that prevented VS2008 `curl.exe` launching on AppVeyor CI: ``` src/curl.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory ``` Ref: https://ci.appveyor.com/project/curlorg/curl/builds/51577006/job/eitypvwlb1rxr11d#L261 FWIW the `curl.rc` embedded manifest wasn't ever enabled for VS2008 CI builds either, because CMake did not pass our custom macro via `CMAKE_RC_FLAGS` to `rc.exe`. For reasons I could not figure out. After this patch the curl build no longer inject its own manifest, and lets the default be applied by linkers and toolchains. It fixes VS2008 shared builds. curl continues to detect the real Windows version via `RtlVerifyVersionInfo()` from `ntdll`. Follow-up to 960d601 curl#12225 Follow-up to 5044909 curl#7810 Follow-up to ebd2132 curl#1221 Ref: curl#15972 Cherry-picked from curl#16394 Closes curl#16453
curl requires Windows XP since 2023. Drop version detection code using `GetVersionEx()` aimed to support earlier Windows versions. With that call deleted, the embedded manifest in `curl.rc` becomes unnecessary. Delete it too, along with the enabler logic in build systems. This allows to stop forcing `/MANIFEST:NO` for MSVC builds. Dropping it fixes VS2008 shared builds, that require an auto-generated SxS (side-by-side assembly) manifest to find their CRT DLLs. This was the issue that prevented VS2008 `curl.exe` launching on AppVeyor CI: ``` src/curl.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory ``` Ref: https://ci.appveyor.com/project/curlorg/curl/builds/51577006/job/eitypvwlb1rxr11d#L261 FWIW the `curl.rc` embedded manifest wasn't ever enabled for VS2008 CI builds either, because CMake did not pass our custom macro via `CMAKE_RC_FLAGS` to `rc.exe`. For reasons I could not figure out. After this patch the curl build no longer inject its own manifest, and lets the default be applied by linkers and toolchains. It fixes VS2008 shared builds. curl continues to detect the real Windows version via `RtlVerifyVersionInfo()` from `ntdll`. Follow-up to 960d601 curl#12225 Follow-up to 5044909 curl#7810 Follow-up to ebd2132 curl#1221 Ref: curl#15972 Cherry-picked from curl#16394 Closes curl#16453
3 participants
After this patch we assume availability of
getaddrinfoandfreeaddrinfo, first introduced in Windows XP. Meaning curlnow requires building for Windows XP as a minimum.
TODO: assume these also in autotools.
Ref: #12221 (comment)
Closes #12225
https://github.com/curl/curl/pull/12225/files?w=1