On 8/11/2020 10:54 AM, David Harris via curl-library wrote:
I apologize if some or all of this is covered elsewhere - I*did* take a browse
through the last
few months of list archives to see if I could see anything, but nothing jumped
out.
First, a little context: I am in the process of developing support for the
infinitely accursed
"OAUTH2" authentication framework, specifically as it is used by GMail. I'm not
going to
waste everyone's time by ranting about OAUTH2 - suffice it to say that as part
of the maze of
steps required to make it work, I need some reliable HTTP client code. While I
could write my
own HTTP/HTTPS handlers, it seemed more logical to use a solid, proven tool
like libCurl
instead.
I have run into three issues with LibCurl as it exists in the Windows
environment, most of
them to do with linkage. I'm hoping to get some insight into how best to deal
with them.
1: Linking to dynamic RTLs. I've read the stuff in WinBuild about CRT linkage,
but while I
can understand why the decision might have been made to go with linking to the
DLL RTL
libraries, it's a problem for me. My program (Pegasus Mail) is pretty much a
niche product
these days, but it's used on practically every version of Windows that still
runs. I've always
static-linked to RTLs to avoid having to include MS redistributables in my
installers: given that
some of the redistributable packages are larger than my entire program, they
constitute
"bloat" on a level I find uncomfortable. Having to use a version of LibCurl
that requires
redistributables which will more than double the size of my distribution, all
so I can do one
badly-designed authentication protocol that's been shoved down our collective
throats by
people who should have been able to do better... Well, let's just say I've got
problems with
that idea.
My inclination, then, is to build a version of LibCurl that uses the
RTLIBCFG=static option, but
this seems to be deprecated so heavily in WinBuild.txt that have to ask: is it
really as
untested and unreliable as WinBuild.txt seems to suggest? In a practical sense,
am I really
going to run into problems with this, or is the warning merely a case of
excessive caution?
2: If I end up building static LibCurl, what libraries do I absolutely*have*
to include for
reasonable levels of operation? I already produce my own OpenSSL builds (for
many of the
same reasons I'm describing here - /MD linkage just won't work for me), but do
I need things
like NGHTTP2, C-ARES or ZLIB for basic HTTP operation? I don't imagine that
those
libraries will be any easier to build for Windows, so if this is going to turn
into a major
production exercise, it may end up being better for me to write my own simple
HTTP code
instead, given how limited my need is. This isn't intended to sound arrogant -
I've written
HTTP servers and both servers and clients for almost every mail protocol
there's ever been,
and I have very extensive TCP/IP code libraries, so I believe that simple HTTP
client code
should be manageable - but I'd sooner use LibCurl if I can, simply because it
has such
impeccable pedigree and because it offers real scope for growth.
3: What MS redistributable does the 7.71.1 build of LibCurl I downloaded from
https://curl.haxx.se/windows/ require? Is the redistributable available
anywhere on the site (I
have access to Visual C 9, 14 and 19)?
Please don't think I'm being negative - I would love to have Curl/LibCurl in my
arsenal of
tools, and once I had it working, I'm sure I would find more and more uses for
it. I admire the
authors, and love the richness - it's just the little niggles I have to sort
out so I can work out
how neat a fit it is for my purposes.
I assume you mean BUILD.WINDOWS.txt which says "RTLIBCFG is rarely used
and therefore rarely tested." That doesn't mean deprecated.
Your build should have at least SSL. I suggest use OpenSSL instead of
the native SSL (Schannel/WinSSL) because you want to run on older
versions of Windows and the native SSL on those older versions does not
support as many SSL protocols or algorithms. OTOH if size is your
primary concern maybe you should consider the native SSL, but you will
run the risk that as servers upgrade their TLS and older Windows doesn't
then your program may not be able to connect to those servers.
The official build of curl for Windows [1] uses the default CRT that
comes with the OS, msvcrt.dll, which is actually some specific version
of the CRT when the OS was shipped. It may be easier for you to consider
using that rather than include a copy of a specific CRT with your program.
There are several ways to build curl for Windows. If you build using
Visual Studio we do not have a configuration that uses the default OS
CRT (or maybe we do and I don't know about it?). Instead build using
mingw/msys.
[1]: https://github.com/curl/curl-for-win
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
