On 9/15/2015 5:16 PM, David Chapman wrote:
https://msdn.microsoft.com/en-us/library/ms235460.aspx
It says CRT (C runtime) objects are valid only for the copy of the CRT
library where they are allocated or set. If the DLL uses a different
copy of the CRT library than the application, then (for example) a
file handle from the application cannot be used within the DLL. This
can cause crashes if the application links to a DLL that was built
elsewhere or at a different time.
This strongly suggests that if libcurl is linked to the application as
a Win32 or Win64 DLL, cURL user code must provide a callback function
- even if the only purpose of the callback is to call fwrite(). Can
someone with more Windows DLL experience confirm this? That will help
with clarification of the CURLOPT_WRITEFUNCTION and CURLOPT_WRITEDATA
wording.
That link sums it up pretty well. Each DLL in a process and the
executable itself could all be using a different CRT. So there could be
many different fwrites. Each CRT's fwrite can only write using FILE
handles it created.
You must pass libcurl the fwrite from the CRT that created the FILE
handle if it's a different CRT. In most cases the code that is setting
the write data to the FILE handle created it so then you can just set
the write function simply as fwrite and libcurl will call the fwrite of
the CRT that code is using. If you are setting write data to a FILE
handle it's possible to get away without setting the write function if
you are certain that the code that created the FILE handle is sharing
the CRT libcurl is using.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
