Replies: 6 comments 7 replies
-
|
This is one of those things I don't think we're going to really know the impact until you do it. I know I've seen some corporate monitors used to mandate 32-bit so they could analyze or hook into programs and there wasn't a 64-bit counterpart. That was many years ago though. I would ask on the lists if anyone is using the official 32-bit curl for Windows instead of 64-bit, and why. edit: save stats for curl for Windows 32-bit and 64-bit downloads might help |
Beta Was this translation helpful? Give feedback.
-
|
Download stats would be excellent. My understanding is that the CDN doesn't count inidividual URLs/downloads, only aggregate traffic, but if there is way to pull this info, it'd help. Also asking the mailing list, indeed. Would you do it? Chocolatey has download stats, but it's not broken down by CPU: (with the caveat that downloads don't necessary match the runtime |
Beta Was this translation helpful? Give feedback.
-
Correct, we don't have any logging from the CDN so all data we have is accumulated for the site and it does not separate between different downloads. We could perhaps consider doing the Windows download specifically use a separate (non-CDNed) "bounce host" for a period of time just to gather this kind of statistics. (ie change the download links to |
Beta Was this translation helpful? Give feedback.
-
|
It would catch direct downloads, but would not those via package managers or other automated ways, unless those get updated to the new endpoints (which in turn can cause confusion when the experiment ends). Could still be useful data. Or, we catch the URL with a web server rule (?) and redirect it to the measured endpoint. This has some risk of breaking downloaders not expecting redirection, but would catch every download. Another angle to consider is that we also distribute libcurl, for use as a dependency for applications. Meaning those apps will also need to be upgraded to 64-bit, along with their other dependencies, which may or may not support 64-bit. I know of at least one such anecdotal case, where a dependency is stuck with the commercial developer shipping 32-bit binaries only. Source code could also have vanished with a 32-bit binary remaining. As for how many people are using these libcurl binaries is of anyone's best guess. IMO not many, but in this case counting downloads isn't indicative, because a developer downloads once, then deploys the dependent app many times. Staggered deprecation may help, first announce, then drop 32-bit builds and downloads – while keeping 32-bit build curl-for-win logic. Wait for feedback. Then remove the logic at a later point. |
Beta Was this translation helpful? Give feedback.
-
Sent to curl-users: If you're using an official curl for Windows 32-bit build instead of 64-bit please tell us why |
Beta Was this translation helpful? Give feedback.
-
|
Thank you Jay! |
Beta Was this translation helpful? Give feedback.
-
|
Number of curl issues/PRs with mentions: |
Beta Was this translation helpful? Give feedback.
-
|
32-bit 32-bit libcurl static lib and DLL: Can only link to a 32-bit application. |
Beta Was this translation helpful? Give feedback.
-
@vszakats Do you mean building via Because I'm using self-built libcurl.dll for x86 and I'd be screwed without this repo. Sadly it's impossible to update the program to x64, it's closed source abandonware with reverse-engineered patches, even for initial cURL support. |
Beta Was this translation helpful? Give feedback.
-
|
@killerbees19 Thanks for your feeback. Yes, this is the unfixable scenario briefly mentioned above. It is an option to keep the x86 build logic, and only disable x86 This path will continue to require x86-specific maintenance, |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I get the point that just dropping the official downloads without removing the actual code/maintenance burden isn't really helping long-term. (And I really appreciate your time-consuming work for this project/repo!) Maybe an "unofficial" state for x86 (self-builds) could be feasible? I mean something like "if it breaks someone [else] needs to fix it" and "not explicitly tested for each cURL release". Because (cross) building cURL (and SSL libs) by hand without this repo is hard. Been there, tried it, failed and switched to the already existing solution. 😅 Sure, at some point I could fork this repo and try to keep it up-to-date for further cURL release at x86. But I'm pretty sure that'd be a big fail after some weeks/months without support. I've not enough knowledge and experience in this area. Last but not least there's no customer or employer who could pay for this stuff, I need it only for nonprofit projects used by ~1000 people around Europe. Most likely as last resort I'd just stick to an old cURL version and hope for the best... Anyways, I respect and understand your upcoming decisions around x86, whatever they'll be. Just a big "I'M STILL USING IT" feedback from my side, even if I'm not using the original downloads. 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @killerbees19! I understand, and can relate to your situation, also knowing such cases first/second-hand. I did discuss ways to "integrate" a 64-bit binary with parts stuck at 32-bit, meaning decoupling them into separate binaries, make them communicate/RPC, or execute each other as bare external binaries. These may be doable, but the effort is non-trivial and not always an option, depending. Maybe something to think about long term. Agreed, that an unofficial status can be viable. It would help some with daily maintenance, binary sizes, CI times. And, effectively mean a little bit more involvement from the community if anything breaks due to no first-hand testing; then see how that goes. FWIW curl-for-win already supports a bunch of features that aren't part of the default or official binaries. |
Beta Was this translation helpful? Give feedback.
-
|
I propose dropping 32-bit official Windows binaries on 2025-Aug-20 (curl release day). We keep 32-bit as a non-default, deprecated, option. The |
Beta Was this translation helpful? Give feedback.
-
Opening this thread to discuss and schedule dropping 32-bit official
Windows curl binaries, leaving x64 and ARM64.
This would make development leaner, builds faster, scripts simpler.
Non-Windows targets already support the latter two only, plus
RISCV64 as an experiment.
Most hardware sold in the last decade+ is 64-bit compatible (including
Atom). Windows Vista / Server 2008 (the minimum our builds require)
do support 64-bit. Windows 10 was the last version supporting 32-bit.
MS stopped offering 32-bit Windows 10 to OEMs in 2020. Windows 11
is 64-bit only.
Cygwin dropped x86 support in November 2022. Most Linux distros
did so earlier.
Windows 11 ARM64 edition can run x64 binaries (according to my
tests). This is important for Chocolatey, because it doesn't support
native ARM64 binaries yet: chocolatey/choco#1803
chocolatey/choco#2172. I haven't checked how it behaves in this
specific scenario. There are already Chocolatey projects that started
dropping 32-bit binaries.
winget and scoop both support native ARM64.
x86/x64 stats for Firefox envs:
https://data.firefox.com/dashboard/hardware
Windows x86 vs x64 vs ARM64 could be an addition to the annual
curl survey.
My proposed, tentative, schedule for this is mid-2025.
edit to clarify: this thread is solely about offering official 32-bit
Windows curl/libcurl binaries as part of the project.
Building curl for Windows 32-bit remains possible and there are
no plans to change it.
Beta Was this translation helpful? Give feedback.
All reactions