Because this library is so very widely used, in practice it is subject to Hyrum's law ABI breaks far beyond what is characterised in the SO_NAME. At the extreme Hyrum's law gets you "spacebar heating", this is not a demand that somehow nothing must change, but an acknowledgement of our reality.
Basically even though Daniel might say "I didn't change the ABI" if your code worked before and now it didn't, as far as you're concerned that's an ABI break. This particularly shows up for changed defaults and for removing stuff that's "unused" except that you relied on it and so now your code doesn't work. Daniel brings up NPN because that seems easy for the public Internet but there have been other examples where a default changed and well... too bad, you were relying on something and now it's changed, but you should have just known to set what you wanted and then you'd have been fine.
Ohh that takes me back, that feature was used heavily in the FXP warez scene (the one the proper warez people looked down on), you’d find vulnerable FTP servers to gain access to, and the best ones would support this. That way you could quickly spread releases over multiple mirrors without being slowed down by your home internet.
Those were fun times, but torrent fits this use case now. You seed the chunk a single time and it magically gets distributed, like you said, without being slowed down by your home internet...
libcurl is part of the macOS API and de-facto standard on any Linux box and commonly available on BSD boxen as well. Microsoft has been shipping curl.exe for a while as well, though not the library.
If Microsoft would also ship the library in %system32%, we would have a truly cross-platform and stable, OS-provided and -patched high-level network protocol client.
As of one of the later releases of Windows 10, "curl.exe" is in System32 (or somewhere else on PATH), but if you type "curl" in a powershell you get the alias. You need to type "curl.exe" to get the binary.
Guessing this is for backwards compatibility with scripts written for the days when it was just PowerShell lying to you.
I never needed curl on Windows, because on OSes that provide a full stack developer experience such things are part of the platform SDK, and rich language runtimes.
It is only an issue with C and C++, and their reliance on POSIX to complement the slim standard library, effectively making UNIX their "runtime" for all practical purposes.
You missed the point. There are more OSes out there. If you had to relearn a brand new "full stack experience" for every OS just to ship a cross-platform app, you wouldn't have any time left for business logic. libcurl is great and it runs everywhere.
And now for a personal opinion: I'll take libcurl over .NET's IHttpClientFactory any day.
I'm a bit confused with the usage of ABI here. I thought compatibility between apps and libs is on the API level, while the ABI sits between machine (cpu intructions) and low level (curl?) lib?
Because this library is so very widely used, in practice it is subject to Hyrum's law ABI breaks far beyond what is characterised in the SO_NAME. At the extreme Hyrum's law gets you "spacebar heating", this is not a demand that somehow nothing must change, but an acknowledgement of our reality.
Basically even though Daniel might say "I didn't change the ABI" if your code worked before and now it didn't, as far as you're concerned that's an ABI break. This particularly shows up for changed defaults and for removing stuff that's "unused" except that you relied on it and so now your code doesn't work. Daniel brings up NPN because that seems easy for the public Internet but there have been other examples where a default changed and well... too bad, you were relying on something and now it's changed, but you should have just known to set what you wanted and then you'd have been fine.
> “third party” transfers over FTP,
Ohh that takes me back, that feature was used heavily in the FXP warez scene (the one the proper warez people looked down on), you’d find vulnerable FTP servers to gain access to, and the best ones would support this. That way you could quickly spread releases over multiple mirrors without being slowed down by your home internet.
Those were fun times, but torrent fits this use case now. You seed the chunk a single time and it magically gets distributed, like you said, without being slowed down by your home internet...
That's progress I believe.
libcurl is part of the macOS API and de-facto standard on any Linux box and commonly available on BSD boxen as well. Microsoft has been shipping curl.exe for a while as well, though not the library.
If Microsoft would also ship the library in %system32%, we would have a truly cross-platform and stable, OS-provided and -patched high-level network protocol client.
(So that probably won't happen)
> Microsoft has been shipping curl.exe for a while as well, though not the library.
I'm not sure if this is accurate. Why do they include a default alias in Powershell for `curl` that points to the `Invoke-WebRequest` cmdlet then?
I've always installed curl myself and removed the alias on Windows. Maybe I've never noticed the default one because of that.
As of one of the later releases of Windows 10, "curl.exe" is in System32 (or somewhere else on PATH), but if you type "curl" in a powershell you get the alias. You need to type "curl.exe" to get the binary.
Guessing this is for backwards compatibility with scripts written for the days when it was just PowerShell lying to you.
https://curl.se/windows/microsoft.html
Hm, since a DLL is a PE file and EXE is a PE file, could one load the EXE as a DLL instead?
There are more OSes out there.
I never needed curl on Windows, because on OSes that provide a full stack developer experience such things are part of the platform SDK, and rich language runtimes.
It is only an issue with C and C++, and their reliance on POSIX to complement the slim standard library, effectively making UNIX their "runtime" for all practical purposes.
You missed the point. There are more OSes out there. If you had to relearn a brand new "full stack experience" for every OS just to ship a cross-platform app, you wouldn't have any time left for business logic. libcurl is great and it runs everywhere.
And now for a personal opinion: I'll take libcurl over .NET's IHttpClientFactory any day.
I'm a bit confused with the usage of ABI here. I thought compatibility between apps and libs is on the API level, while the ABI sits between machine (cpu intructions) and low level (curl?) lib?