FYI @rainers.

I've checked the deps of the x64 libcurl.dll, and it's looking very good:

>dumpbin /dependents libcurl-x64.dll
[…]
  Image has the following dependencies:

    bcrypt.dll
    CRYPT32.dll
    KERNEL32.dll
    Normaliz.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-private-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-utility-l1-1-0.dll
    USER32.dll
    WLDAP32.dll
    WS2_32.dll

I.e., they even link the MSVCRT statically, so no need for the MSVC++ redistributable.

Looking at #3638, I think the main reason for the former custom builds was the static lib (in MSVC-compatible .lib format), and making that static lib usable with the bundled MinGW-based libs. The DONT_USE_RECV_BEFORE_SEND_WORKAROUND workaround is almost certainly obsolete by now (or handled by the official builds).

Using the official builds should be much better wrt. Antivirus problems, and allows us much more easily to keep the bundled version reasonably up-to-date (edit: oh, trivial to use the very latest version, updated accordingly). Plus the feature set is most likely much higher (libssh2, zstd, brotli, …).