in reply to Re^5: Testing Time::Piece on Windows/VC
in thread Testing Time::Piece on Windows/VC

Hm. When I look at the mscvrt.dll that gets imported by perl510.dll from my AS 64-bit build, is loaded from c:\windows\system32\msvcrt,.dll it is versioned as Windows NT CRT DLL 7.0.6001.18000.

Now, if VC++v7 was 32-bit only. And I have VC++v9, which is also "wrong", presumably--assuming some kind of logic--the compiler that comes with SDK2003--which is the "correct version"--must be VC++v8.

Now, on my system I have 53 different copies of various msvcr*.dll, amongst them at least 8 different msvcr80.dlls: 

05/01/2002  11:37           344064 MSVCR70.dll
05/01/2002  11:37           344064 msvcr70.dll
10/02/2006  21:59           348160 msvcr71.dll
21/02/2003  04:42           348160 msvcr71.dll
21/02/2003  04:42           348160 msvcr71.dll
21/02/2003  14:42           348160 msvcr71.dll
16/10/2007  12:40           348160 msvcr71.dll
21/09/2006  09:44           348160 msvcr71.dll
10/02/2006  21:59           348160 msvcr71.dll
08/04/2008  14:13           348160 msvcr71.dll
01/05/2009  21:02           348160 msvcr71.dll
21/02/2003  13:42           348160 msvcr71.dll
21/02/2003  04:42           348160 msvcr71.dll
14/04/2005  17:11           491520 msvcr80.dll
24/06/2004  22:00           585728 msvcr80.dll
22/09/2005  21:05           626688 msvcr80.dll
15/08/2007  22:33           626688 msvcr80.dll
01/12/2006  21:03           626688 msvcr80.dll
15/08/2007  22:33           626688 msvcr80.dll
02/11/2006  06:33           626688 msvcr80.dll
24/03/2009  01:06           626688 msvcr80.dll
01/12/2006  22:03           626688 msvcr80.dll
27/07/2008  18:03           635904 msvcr80.dll
21/01/2008  02:48           635904 msvcr80.dll
20/10/2006  01:12           794112 msvcr80.dll
29/10/2009  14:17           796672 msvcr80.dll
21/01/2008  02:48           805888 msvcr80.dll
27/07/2008  18:01           805888 msvcr80.dll
13/03/2009  08:34           627200 msvcr90.dll
06/11/2007  22:02           627200 msvcr90.dll
29/07/2008  15:05           655872 msvcr90.dll
06/03/2009  03:30           655872 msvcr90.dll
15/03/2009  10:52           655872 msvcr90.dll
29/07/2008  08:05           655872 msvcr90.dll
13/03/2009  09:00          1180672 msvcr90d.dll
15/03/2009  10:57          1180672 msvcr90d.dll
29/07/2008  08:05          1180672 msvcr90d.dll
13/03/2009  08:59          1352704 msvcr90d.dll
23/12/2003  11:08           254005 Msvcrt.dll
07/03/2000  00:00           278581 Msvcrt.dll
01/02/1999  23:00           266293 msvcrt.dll
06/05/2001  11:14           266293 msvcrt.dll
19/06/2003  19:05           286773 msvcrt.dll
11/05/2002  23:56           290869 msvcrt.dll
21/01/2008  02:49           621056 msvcrt.dll
21/01/2008  02:49           621056 msvcrt.dll
21/01/2008  02:49           680448 msvcrt.dll
21/01/2008  02:49           680448 msvcrt.dll
02/11/2006  09:46           253952 msvcrt20.dll
02/11/2006  09:46           253952 msvcrt20.dll
20/02/1996  01:03           326656 Msvcrt40.dll
02/11/2006  09:41            61440 msvcrt40.dll
02/11/2006  09:41            61440 msvcrt40.dll

[download]

As there is a v8-specific version of the CRT, the question is why does the AS built binary load the "generic" msvcrt.dll, in preference to the specific version? Presumably, the existance of the specific version means it must get used under some circumstances.

Or, more interestingly, is there some way to request (or default) extensions built using the v9 compiler to import their CRT requirements from the generic msvcrt.dll supplied with the platform (per the AS binary), rather than the tookit specific msvcr90.dll as currently?

The linker has options: /DEFAULTLIB:library /NODEFAULTLIB[:library] along with the compilers /MT & /MD options.

The generated makefile use (amongst others):-nodefaultlib Set LIBC=msvcrt.lib and add the latter to the list of filesnames supplied ot the linker. But all of that does no good (for this problem at least) as the all the .dll references within the msvcrt.lib that comes with the v9 compiler are to msvcr90.dll.

Probably, none of this means anything. Maybe, it was just a policy change on MS behalf between the v8 and v9 compilers that causes the AS binaries to import from msvcrt.dll (despite the existance of msvcr80.dll), and extensions built with v9 to import from msvcr90.dll? But somehow that doesn't ring true. At least not completely.

I'm going to pull the AS sources ikegami linked to and try building it with the v9 compiler and see which CRT ends up getting used. If it links against the generic, the problem might be solvable by modifying the makefile generation to match the AS build configuration. Worth a shot at least.

I don't know how you located the v8/2003sdk downloads? Every search I tried refused point blank to locate it. The one page I found that discussed the 2003 SDK, redirected me to the 2008 SDK when I tried the download link :(

The other problem is that AFAIK, it is impossible to run the two concurrently, and I have a couple of things that I think require the 2008 SDK.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"I'd rather go naked than blow up my ass"

Replies are listed 'Best First'.
Re^7: Testing Time::Piece on Windows/VC
by syphilis (Archbishop) on Jan 28, 2010 at 07:28 UTC
    And I have VC++v9, which is also "wrong", presumably--assuming some kind of logic--the compiler that comes with SDK2003--which is the "correct version"--must be VC++v8

    By my understanding of the version numbering, you have version 9.0 (version number starts with 15.00) and I have version 8.0 (version number starts with 14.00). Mine has the same full version number as the compiler that built x64 ActivePerl (14.00.40310.41).

    I have it in my head that my x64 compiler, despite being a version 8.0 compiler, actually uses the msvcrt.dll runtime. And I also have it in my head that ActiveState elected to use it (at least partly) for that reason - though I don't recall precisely how that line of reasoning ran.

    I don't know how you located the v8/2003sdk downloads?

    Someone (probably Jan Dubois) gave it to me ... I can never find anything for myself on the MS website :-)

    Let us know how you go with the perl you build with your version 9.0 compiler. I've got my money on it being able to build Time::Piece without any test failures. I'd be interested to find out for sure.

    Cheers,
    Rob
[reply]

      I conclude that you're right that this is the result of the disparate CRTs.

      In particular, the fact that both CRTs probably have seperate copies of the environment which defeats T::P's attempts to maintain Perl's copy, the CRT copy and the process' copy in a coherent state

      If I install T::P 1.16 via PPM into my AS-binary dist, it works fine. Equally, if I build it using a Perl built from AS sources and VC++ v9, it passes all the tests. Despite that the home-built ASPerl also links to both msvcrt.dll & msvcr90.dll!?

      I also think it could be 'fixed'.

      If the fixups and work arounds to the tz* functions in T::P, were factored back into the win32 perl core, and exported from perl510.dll--and T::P imported them from there--the problem would disappear. (I think :)

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        There are some extensive comments in Piece.xs about the CRT, the environment (especially $ENV{TZ}) and tzset - specifically: 
         * Therefore, we need to retrieve the value of $ENV{TZ} and call CRT
 * putenv() to update the CRT copy of the environment (if it is differ
+ent)
 * whenever we're about to call tzset().

        [download]
        And the 2 failing tests I get when I "mix runtimes" come from: 
        SKIP: {
    skip "can't register TZ changes in a pseudo-fork", 2 if $is_pseudo
+_fork;
    local $ENV{TZ} = "EST5";
    Time::Piece::_tzset();  # register the environment change
    my $lt = localtime;
    cmp_ok(scalar($lt->tzoffset), 'eq', '-18000');
    cmp_ok($lt->strftime("%Z"), 'eq', 'EST');
}

        [download]
        I expect that when Time::Piece is built with a compiler that uses a different runtime, Time::Piece::_tzset() registers the environment change ok, but registers it with the *wrong* runtime (for the purposes of Time::Piece, at least).

        Not sure how this could be fixed. With which runtime will Time::Piece::_tzset() register the change ?
        With the runtime of the compiler that built perl ? ... or with the runtime of the compiler that built Time::Piece ?
        I suspect it must be the latter, and the trick would be to get Time::Piece::_tzset() to register the change with the former. (Or vice-versa :-)

        Cheers,
        Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom