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.