mingw-users

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

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

The page at http://www.mingw.org/wiki/C99 says: "The MinGW port of GCC 
uses Microsoft's original (old) Visual C runtime, MSVCRT, which was 
targeted by Microsoft Visual Studio 6 (released in 1998)."

This appears to imply that MinGW does not use the version of msvcrt.dll 
supplied by Windows OS.
This agrees with Microsoft that has been saying for a while already 
http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.71%29.aspx that 
msvcrt.dll supplied by Windows OS should not be used by user applications.

I am running MinGW 4.8.1 on Windows XP SP3 and could not find any 
msvcrt.dll or msvsrxx.dll in any MinGW directories; all versions I 
found, were in system directories and in the directories of other 
applications.

So which msvcrt.dll or msvsrxx.dll does MinGW use?

Please reply to the list as I believe the answer may be helpful to others.

Thanks
Baruch Youssin

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

[Eli Z. <el...@gn...>]

> Date: Mon, 25 Aug 2014 21:02:38 +0300
> From: Baruch Youssin <quq...@ya...>
> 
> I am running MinGW 4.8.1 on Windows XP SP3 and could not find any 
> msvcrt.dll or msvsrxx.dll in any MinGW directories; all versions I 
> found, were in system directories and in the directories of other 
> applications.
> 
> So which msvcrt.dll or msvsrxx.dll does MinGW use?

MinGW by default links your applications against the msvcrt.dll that
is provided with Windows.  You can find it in the system32 directory.

Regardless of what MS says on MSDN (which AFAIK is mainly aimed and
MSVC developers), you can safely use msvcrt.dll in your MinGW
programs.

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

[Eli Z. <el...@gn...>]

> Date: Thu, 28 Aug 2014 10:58:48 +0300
> From: Baruch Youssin <quq...@ya...>
> CC: Baruch Youssin <quq...@ya...>
> 
> >> 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.

Yes.

> 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.

I don't think so.  I also used XP, so our msvcrt versions should be
the same.

> >> Problem 2:
> >> My bigger problem was an attempt to run the same code on a 64 bit
> >> machine: I tried it on a Windows Server 2008 64 bit in VS 2010 against
> >> its default library msvcr100.dll.  I found that difftime worked
> >> correctly but gmtime went wrong: it thought the current time zone offset
> >> of Jerusalem was 2 hours (GMT+2) while in fact it was 3 hours due to
> >> Daylight Savings Time as my desktop correctly displayed.
> > Can't help you here: I don't use Studio, and don't know anything about
> > how to set up time routines there.
> As far as I see, the time routines are part of the standard run-time 
> library and need not be set up in any way.

The problem I alluded to is what do you get when you use time_t and
related functions.  With some compiler switches, you get the 32-bit
version of time_t, with others you get a 64-bit version, and the same
with the functions that accept and return these values.

I don't know what is the default in Studio, and how to get the other
version.  But if your program expects a 32-bit value, but calls a
function that produces or accepts a 64-bit value, you can easily get
invalid results.

> >> Determining the current time zone is known to be difficult on
> >> Windows computers
> > ??? I don't find it difficult at all.  E.g., try the %z format in
> > strftime.
> On my Windows XP Mingw4.8.1 Eclipse 4.3.2 computer %z format in strftime 
> returns the same thing as %Z format: "Jerusalem Daylight Time".  It does 
> not return +300 expected.  This is in agreement with 
> http://msdn.microsoft.com/en-us/library/fe06s4ak.aspx .  I guess MS has 
> not yet implemented C99 in which %z belongs.

Well, yeah, but note that it got the time zone and the daylight
savings setting correctly.  So msvcrt time routines do work correctly.

> This article also explains what happens in the Registry so that it 
> cannot be reliably used to find out the correct time zone info.

What can I say? I never experienced such problems (although I don't
use Java).

But why talk about hypothetical problems and complaints by others?
Just install mingwrt 3.20 instead of 4.x, and try again.  I would be
very surprised if you'd still see any problems with time functions in
MinGW programs.  Certainly difftime works as expected.

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

[Keith M. <kei...@us...>]

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.

-- 
Regards,
Keith.

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

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

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.
>

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.
>>
>
>
>

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

[Eli Z. <el...@gn...>]

> Date: Sun, 31 Aug 2014 16:56:17 +0300
> From: Baruch Youssin <quq...@ya...>
> 
> 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).

Don't pay attention to MSDN references to msvcrNNN.dll, they are there
mostly for the benefit of MSVC and Visual Studio users.

With MinGW, you shouldn't use those msvcrNNN DLLs, unless under very
special circumstances, and _only_ if you know what you are doing and
why.  Otherwise, always use msvcrt.dll (which GCC will link against
automatically).

> Thanks for this clarification, and good luck sorting out all this.

If you use MinGW runtime 3.x and msvcrt.dll, all this is already
sorted out for you.

> BTW, I presume that all this refers to all other time functions, not 
> just to difftime.

Yes.

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

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

I continued this topic as a private conversation with Eli Zaretskii 
<el...@gn...> as I was not sure it is worthwhile for the list.
By Eli's suggestion, I post here the entire track this far, starting 
with the old and finishing with my comments on the most recent message 
from Eli.


On 08/26/2014 04:41 PM, Baruch Youssin wrote:
> Many thanks for your prompt clarification.
> As I found this article 
> http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/ 
> , I understood that indeed msvcrt.dll supplied by Windows, is updated 
> and the difference between different verstions of msvcr.. is not in 
> the standard C runtime library but rather in other MS 
> functionalities.  Thus, I understood why linking against it is the 
> best solution for MinGW.
>
> This helped me decide that the native time and time zone functions 
> provided by MS, are unreliable to the point that they should not be 
> used.  (I had one case of difftime returning the first parameter 
> instead of the difference on Windows XP SP3 under MinGW against 
> msvcrt.dll - which is not a big deal as a call to difftime under MinGW 
> can be replaced by subtracting time_t values - and another case of 
> gmtime getting the current time zone offset incorrectly on Windows 
> Server 2008 under VS2010 against msvcr100.dll.)
>
> Many thanks again
> Baruch Youssin
>
> On 08/25/2014 09:44 PM, Eli Zaretskii wrote:
>>> Date: Mon, 25 Aug 2014 21:02:38 +0300
>>> From: Baruch Youssin <quq...@ya...>
>>>
>>> I am running MinGW 4.8.1 on Windows XP SP3 and could not find any
>>> msvcrt.dll or msvsrxx.dll in any MinGW directories; all versions I
>>> found, were in system directories and in the directories of other
>>> applications.
>>>
>>> So which msvcrt.dll or msvsrxx.dll does MinGW use?
>> MinGW by default links your applications against the msvcrt.dll that
>> is provided with Windows.  You can find it in the system32 directory.
>>
>> Regardless of what MS says on MSDN (which AFAIK is mainly aimed and
>> MSVC developers), you can safely use msvcrt.dll in your MinGW
>> programs.
>>
>> ------------------------------------------------------------------------------ 
>>


On 08/26/2014 05:55 PM, Eli Zaretskii wrote:
>> Date: Tue, 26 Aug 2014 16:41:49 +0300
>> From: Baruch Youssin <quq...@ya...>
>> CC: Baruch Youssin <quq...@ya...>
>>
>> Many thanks for your prompt clarification.
> You are welcome.
>
>> This helped me decide that the native time and time zone functions
>> provided by MS, are unreliable to the point that they should not be
>> used.
> Please post the details.  The only problems in this area that I ever
> bumped into was with the latest MinGW runtime 4.x, which attempts by
> default to use the 64-bit time_t data type and associated msvcrt
> functions, but does that in a way that trips on a few problems, and
> can easily cause application bugs.
>
> My solution is not to use MinGW runtime 4.x yet.
>
> If you use version 3.x of the runtime, please describe what problems
> you see.
>
>> (I had one case of difftime returning the first parameter instead
>> of the difference on Windows XP SP3 under MinGW against msvcrt.dll -
> Can you show a test program that reproduces the problem?
>
>> and another case of gmtime getting the current time zone offset
>> incorrectly on Windows Server 2008 under VS2010 against
>> msvcr100.dll.)
> Again, unless you use mingwrt 4.x, please consider showing the
> details.


On 08/26/2014 08:44 PM, Baruch Youssin wrote:
> Here are the details:
> I am trying to create a DLL running a simple code calling four 
> functions: time(.), gmtime(.), mktime(.) and difftime(.).  The code is 
> taken from 
> http://www.codeproject.com/Articles/144159/Time-Format-Conversion-Made-Easy 
> and is as follows:
>
>       time_t now_utc = time(0);
>       struct tm* ptm_now_UTC = gmtime(&now_utc);
>       time_t now_anti_local = mktime(ptm_now_UTC);
>       double OffsetSeconds = difftime(now_utc, now_anti_local);
>       return (int)  round(OffsetSeconds/60.0);
>
> 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.  This is not a big deal as MinGW 
> agrees to subtract time_t values and does it correctly.  (time_t is 
> indeed defined as __time64_t.)
> Do you think this could have been caused by MinGW?
>
> Problem 2:
> My bigger problem was an attempt to run the same code on a 64 bit 
> machine: I tried it on a Windows Server 2008 64 bit in VS 2010 against 
> its default library msvcr100.dll.  I found that difftime worked 
> correctly but gmtime went wrong: it thought the current time zone 
> offset of Jerusalem was 2 hours (GMT+2) while in fact it was 3 hours 
> due to Daylight Savings Time as my desktop correctly displayed.
>
> My feeling was that the problem at least in the second case is with 
> msvcrt rather than anything else.  Determining the current time zone 
> is known to be difficult on Windows computers, and this is what I was 
> trying to accomplish.  It appears to me that msvcrt cannot be relied 
> upon to determine the current time zone consistently, whether I use MS 
> VS or MinGW.
>
> I would appreciate any further comments.
>
> If you feel any of this should be posted, please do this.
>
> Thanks for all your help.
>
> Best regards
>
> Baruch Youssin


On 08/26/2014 09:03 PM, Eli Zaretskii wrote:
>> Date: Tue, 26 Aug 2014 20:44:08 +0300
>> From: Baruch Youssin <quq...@ya...>
>> CC: Baruch Youssin <quq...@ya...>
> Not sure it's a good idea to make this a private conversation.  I
> suggest to add the list back.
>
> Anyway...
>
>> I am trying to create a DLL running a simple code calling four
>> functions: time(.), gmtime(.), mktime(.) and difftime(.).  The code is
>> taken from
>> http://www.codeproject.com/Articles/144159/Time-Format-Conversion-Made-Easy
>> and is as follows:
>>
>>         time_t now_utc = time(0);
>>         struct tm* ptm_now_UTC = gmtime(&now_utc);
>>         time_t now_anti_local = mktime(ptm_now_UTC);
>>         double OffsetSeconds = difftime(now_utc, now_anti_local);
>>         return (int)  round(OffsetSeconds/60.0);
>>
>> 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.
>
>> This is not a big deal as MinGW agrees to subtract time_t values and
>> does it correctly.  (time_t is indeed defined as __time64_t.)  Do
>> you think this could have been caused by MinGW?
> That'd be my first suspicion, yes.  MinGW runtime v4.x is broken wrt
> time functions (and functions that depend on time functions, like
> 'stat' and 'findfirst').  I suggest to downgrade to mingwrt-3.20 and
> w32api-3.17, and then try again.  (You don't need to downgrade your
> GCC and Binutils, they will work with the 3.x runtime just fine.)
>
>> Problem 2:
>> My bigger problem was an attempt to run the same code on a 64 bit
>> machine: I tried it on a Windows Server 2008 64 bit in VS 2010 against
>> its default library msvcr100.dll.  I found that difftime worked
>> correctly but gmtime went wrong: it thought the current time zone offset
>> of Jerusalem was 2 hours (GMT+2) while in fact it was 3 hours due to
>> Daylight Savings Time as my desktop correctly displayed.
> Can't help you here: I don't use Studio, and don't know anything about
> how to set up time routines there.
>
>> My feeling was that the problem at least in the second case is with
>> msvcrt rather than anything else.
> I doubt that.  MinGW programs use msvcrt as well, and yet your test
> program works for me here.
>
>> Determining the current time zone is known to be difficult on
>> Windows computers
> ??? I don't find it difficult at all.  E.g., try the %z format in
> strftime.
>
>> It appears to me that msvcrt cannot be relied upon to determine the
>> current time zone consistently, whether I use MS VS or MinGW.
> That's definitely not true.  Modern Windows systems have a detailed
> database of time-zone information in their Registry, and the msvcrt
> functions are perfectly capable of using that information.
-----------------------------
My comments:

>> 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.


>> Problem 2:
>> My bigger problem was an attempt to run the same code on a 64 bit
>> machine: I tried it on a Windows Server 2008 64 bit in VS 2010 against
>> its default library msvcr100.dll.  I found that difftime worked
>> correctly but gmtime went wrong: it thought the current time zone offset
>> of Jerusalem was 2 hours (GMT+2) while in fact it was 3 hours due to
>> Daylight Savings Time as my desktop correctly displayed.
> Can't help you here: I don't use Studio, and don't know anything about
> how to set up time routines there.
As far as I see, the time routines are part of the standard run-time 
library and need not be set up in any way.  They are supposed to work 
correctly when called.  If they do not, they cannot be relied upon.  
Since there is no reason to assume that msvcrt is consistently better 
than msvcr100, it cannot be relied upon either.

>> My feeling was that the problem at least in the second case is with
>> msvcrt rather than anything else.
> I doubt that.  MinGW programs use msvcrt as well, and yet your test
> program works for me here.
As I wrote above, your msvcrt may be different from mine, and this seems 
to me to be the only reason for the difference in behavior.

>> Determining the current time zone is known to be difficult on
>> Windows computers
> ??? I don't find it difficult at all.  E.g., try the %z format in
> strftime.
On my Windows XP Mingw4.8.1 Eclipse 4.3.2 computer %z format in strftime 
returns the same thing as %Z format: "Jerusalem Daylight Time".  It does 
not return +300 expected.  This is in agreement with 
http://msdn.microsoft.com/en-us/library/fe06s4ak.aspx .  I guess MS has 
not yet implemented C99 in which %z belongs.

>> It appears to me that msvcrt cannot be relied upon to determine the
>> current time zone consistently, whether I use MS VS or MinGW.
> That's definitely not true.  Modern Windows systems have a detailed
> database of time-zone information in their Registry, and the msvcrt
> functions are perfectly capable of using that information.
Java has had trouble determining the current time zone on Windows 
machines for many years (since 2000?).  Bugs have been filed with Sun 
and Oracle and rejected as unreproducible.  You can read about this 
here: 
http://techtavern.wordpress.com/2010/04/15/java-and-incorrect-timezone-on-windows-xp/
This article also explains what happens in the Registry so that it 
cannot be reliably used to find out the correct time zone info.
There are plenty other similar complaints on the net.
Just six months ago, in the beginning of 2014, Java on my own Windows XP 
reported the current time zone as America/Bahia instead of 
Asia/Jerusalem; an update from Java has fixed this recently.
And my experience with Windows Server 2008 that has gmtime erring in the 
current offset shows that msvcr.. is not reliable either.

Best regards

Baruch