As a primarily dev who grew up on Windows and has just used curl for some basic stuff, wonder what's so hard. That is, on the face of it, curl seems like a quite basic application in the grand scheme of things. Would have been nice with some specific, juicy details.
I've worked on a medium sized open-source project (~500kLOC) that was supported on Windows, Linux and MacOS, so I'm not unfamilar with cross-platform support. For us, MacOS was by far the weirdest of the bunch.
One of the complaints was the path separators. We solved that by just consistently using / everywhere internal. Any supplied paths would get converted right away. Not really an issue to write home about IMHO.
There are bigger specs like for wifi where it's thousands of pages, but I don't think you can classify a client that implements even half of the HTTP specs as basic.
Yeah that's what I mean, on the face of it there's not all that much platform specific code should be required for that.
Sure handling all the edge cases of HTTP and whatnot isn't trivial, but almost all of that should be platform neutral so not relevant for this discussion.
Now granted I know HTTP/2 and HTTP/3 are different beasts. But that's why I said it would have been nice with some concrete examples. It's always interesting to learn about issues and pitfalls you've never considered, or similar.
In other words, curl attempts to fully implement the RFCs, which have many, many edge cases and weird features, so a seemingly simple application balloons into a massive undertaking.
I've worked on a medium sized open-source project (~500kLOC) that was supported on Windows, Linux and MacOS, so I'm not unfamilar with cross-platform support. For us, MacOS was by far the weirdest of the bunch.
One of the complaints was the path separators. We solved that by just consistently using / everywhere internal. Any supplied paths would get converted right away. Not really an issue to write home about IMHO.