A lot of comments here aren’t acknowledging the actual complaint, which is:
> everything from path separators, stupid shells, charsets, to not excepting non-sockets in select, no std libc, ownershipd of memory passed to DLLs, ...
Not having a standard-compliant libc seems really annoying. Also, curl is an IO heavy library. Not having select work as it does on other platforms or not having libc work as expected is going to be really annoying.
> Not having a standard-compliant libc seems really annoying
There are several standard-compliant libc implementations (and C implementations in general) available on Windows, pick any one that you fancy. And why should an OS even ship a default runtime for some random programming language anyhow? Just because it was written in that programming language so it gets a preferential treatment? That's breaking the abstraction layering.
If you want to allow people to build curl using various different compilers (and old versions of them) on Windows, it needs to support all their libc’s.
And at runtime, libcurl could find itself using a different libc from the application, so a buffer malloc’d in libc can’t be passed to free() by the app.
> If you want to allow people to build curl using various different compilers (and old versions of them) on Windows, it needs to support all their libc’s.
That sounds like a problem that could be solved by not doing that and picking one.
> And at runtime, libcurl could find itself using a different libc from the application, so a buffer malloc’d in libc can’t be passed to free() by the app.
Yes, it's something anybody who has been seriously programming for Windows has been aware since forever. Which is why libraries and plugins generally expose FreeX() for every X they allocate and return.
> And at runtime, libcurl could find itself using a different libc from the application, so a buffer malloc’d in libc can’t be passed to free() by the app.
That's a general issue with C plugins/libraries. You cannot even assume that objects are allocated with malloc() because the library might use its own memory allocator, object pool, etc.
> Not having a standard-compliant libc seems really annoying. Also, curl is an IO heavy library.
Emphasis on library, curl is not just a command line tool. Calling a library compiled with one version of libc (actually msvcrXX.dll) from a program or library compiled with a different version of libc (for instance, msvcr71.dll vs msvcr81.dll) means things like file descriptors (not just FILE structs, but also numeric file descriptors) aren't shared between them.
Yes, and if you link against something compiled with cc3290.dll (or whatever Borland's C runtime was called) you too will have bad time unless you structure your library with explicit understanding that there may be any number of C runtimes inside one process, including zero. Expose CreateX()/FreeX() from your library or arrange that the process would on start up pass to your library a table of allocation/deallocation functions to use and use those.
Nowadays there is the Universal C Runtime you could link against. It's available on Windows 10 out of the box, and via Windows Update or redistributable on Windows Vista/7/8.1.
The path separator should just be fixed. Almost all the APIs accept '/', it's just that the old "cmd" utilities don't because they use / as the option separator (from CP/M), not "-".
That would probably require killing CMD, which would be a big compatibility break. I suspect it could be turned into a shim layer for corporates who need to keep running BAT files.
Not accepting non-sockets in select() .. the native API (WaitForMultipleObjects) is much more flexible, but it doesn't look like select().
No one is saying that it's impossible to develop curl for Windows. Needing to either work around a non-standard libc, require the user install a standard compliant libc, or ship your own libc with custom methods like FreeX is strange and hard compared to other operating systems. Same with using something like WaitForMultipleObjects vs select and path separators.
If you're a Windows-first developer, you're probably used to these things, but to non-Windows developers, Windows is strange and annoying.
I tried to port one of our server applications to Windows. I eventually gave up because our service would remove files that were still open. To me, it's crazy that Windows doesn't allow you to do that. This also means you can't use a tool like SSH or SCP. If you accidentally kill the local SCP process while the file is transferring, you need to remotely connect to the destination and kill the remote SCP process to allow that file to be modified again.
Except the APIs you need to use to avoid the 260-character MAX_PATH limit (without depending on both an obscure group policy setting and a setting on the application manifest, and keep in mind that curl is also a library so it cannot control the application manifest). AFAIK, the "\\?\" trick to extend the limit to 32767 characters requires both absolute paths and the use of a backslash (\) as the path separator.
> everything from path separators, stupid shells, charsets, to not excepting non-sockets in select, no std libc, ownershipd of memory passed to DLLs, ...
Not having a standard-compliant libc seems really annoying. Also, curl is an IO heavy library. Not having select work as it does on other platforms or not having libc work as expected is going to be really annoying.