in reply to ActivePerl dies in msvcrt.dll under Windows

I'm not sure I have useful advice, but some observations.

msvcrt.dll is the MicroSoft Visual C run time dynamic link library. The main run time library for programs compiled with Microsoft Visual C.

If your Perl installation worked correctly with the previous version of msvcrt.dll, try putting a copy in the perl/bin directory. The perl interpreter will use the one in its' local directory rather than using the system version/copy.

That should (may) solve the problem locally. You may still have issues if you need to distribute your script to other systems.

  • Comment on Re: ActivePerl dies in msvcrt.dll under Windows

Replies are listed 'Best First'.
Re^2: ActivePerl dies in msvcrt.dll under Windows
by hawtin (Prior) on Nov 28, 2005 at 20:59 UTC

    The name makes sense, I assume that ActivePerl is compiled with Visual C then.

    I tried putting a version of the dll in:

    • The perl bin directory
    • Another bin directory early in my path
    • The local directory
    • My local lib (where a whole load of modules live)

    The program still dies and the error message always shows that the msvcrt.dll that is in C:/windows/system32 is the one that dies. As I mentioned in desperation I tried changing that but the OS refuses to boot

    So, yes I agree that is how I thought that DLLs worked under Windows, but for this case my understanding was wrong

    Since I am always running in the Command window I wondered if that is loading up the DLL and then refusing to dislodge it with an earlier version? As I said I am no Windows expert

[reply]
      Since I am always running in the Command window I wondered if that is loading up the DLL and then refusing to dislodge it with an earlier version?

      No. That will not be the cause.

      When you placed your dll in these directories, did you also ensure that the directory in question also appeared earlier in the path than the c:\windows\system32?

      The only reason why it would favour the windows\system32 copy over the others paths, is if the former appears earlier in the path. For more information, see the link in Re: Perl/TK application and DLL hell on Win32, and the quote in Re^3: Perl/TK application and DLL hell on Win32.

      I've just tried this with the 5 different versions of msvcrt.dll that I found on my system dating from 1999 through to 2004, and they all worked (for a cursory test) in conjunction with Perl5.8.7 (AS813).

      There is another way that might help you resolve the issues involved, though I wouldn't recommend it for production use.

      If you rename the old dll to some other name (sticking to 6 characters) and then binary edit both perl.exe & perl58.dll (once in the former and twice in the latter. MAKE BACKUPS FIRST!!!), to change the references to 'mscvrt' to whatever name you gave the old version, you will ensure that only that old dll will be used.

      Again, I just tried this with the oldest and newest versions of msvcrt on my system, and binary edited copies of perl5.8.7.exe and perl58.exe from as813, and they all passed cursory testing of using pack & unpack on unicode data.

      If ensuring that you pick up the old version of the dll doesn't fix your problem, you will need to provide a cut down version to demonstrate it, or load up a binary debugger to find out what in your code starts the chain to the point of failure.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom