Re^2: ActivePerl dies in msvcrt.dll under Windows

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

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

Replies are listed 'Best First'.
Re^3: ActivePerl dies in msvcrt.dll under Windows by BrowserUk (Patriarch) on Nov 28, 2005 at 23:24 UTC
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]

Replies are listed 'Best First'.

Re^3: ActivePerl dies in msvcrt.dll under Windows
by BrowserUk (Patriarch) on Nov 28, 2005 at 23:24 UTC

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]