Re: [Mingw-users] Which msvcrt.dll does MinGW use?

[Baruch Y. <quq...@ya...>]

Keith,
After looking into "Continuing support for Windows Pre-XP in MinGW?" 
track, I have realized that you are actually keeping track of different 
versions of msvcrt.dll that Microsorft has ever released!
I admire this!


On 08/31/2014 04:56 PM, Baruch Youssin wrote:
> Thanks, Keith, for the reference 
> http://sourceforge.net/p/mingw/bugs/2152/ .  I understand that MinGW 
> 4.x implements
> "MSDN http://msdn.microsoft.com/en-us/library/3wbd7281.aspx tells us:
>     difftime is an inline function that evaluates to either 
> _difftime32 or _difftime64 depending on whether _USE_32BIT_TIME_T is 
> defined."
> However, this MSDN page 
> http://msdn.microsoft.com/en-us/library/3wbd7281.aspx refers to Visual 
> Studio 2013, i.e. msvcr110.dll.  When I choose on this page Visual 
> Studio .NET 2003 instead of Visual Studio 2013 (this corresponds to 
> msvcr71.dll), I get to 
> http://msdn.microsoft.com/en-us/library/3wbd7281%28v=vs.71%29.aspx 
> which mentions neither _difftime32 nor _difftime64, only difftime.
> The actual msvcrt.dll is not guaranteed by Microsoft --as both pages 
> say-- and may function either way (apparently, on newer Windows it has 
> _difftime32 and _difftime64 as above, and on XP it has only difftime).
> Thanks for this clarification, and good luck sorting out all this.
> BTW, I presume that all this refers to all other time functions, not 
> just to difftime.
>
>
>
>
> On 08/29/2014 10:34 PM, Keith Marshall wrote:
>> On 28/08/14 08:58, Baruch Youssin wrote:
>>>>> Problem 1:
>>>>> I am running MinGW 4.8.1 on Windows XP SP3 32 bit with Eclipse 4.3.2.
>>>>> The problem on this installation is that difftime returns its first
>>>>> parameter instead of the difference.
>>>> That's not what I see here: I get the (expected) result of 180, which
>>>> is the UTC offset in my locale.
>>> I presume that you have been running MinGW 4.8.1 to test this.  If so,
>>> it seems to me that the difference between your installation and 
>>> mine is
>>> in msvcrt that comes with the OS.  Hence, my problem here is not with
>>> MinGW but rather with msvcrt.
>> Does http://sourceforge.net/p/mingw/bugs/2152/ give you any hints as to
>> why the behaviour you are seeing might be expected, if you are using
>> mingwrt-4.0?  And why it works correctly for Eli, with mingwrt-3.20?
>>
>> Like Eli says: "don't use mingwrt-4.0; it is too unreliable". Your
>> problem *is* with MinGW -- specifically mingwrt-4.0 -- *not* MSVCRT.
>>
>
>
>