Neither msvcr70 or msvcr71 cover all of the NT Msvcrt exports.

msvcr70 is missing:

_get_heap_handle

msvcr71 is missing:

_ctype

void * bad_cast::`scalar deleting destructor'(unsigned int)

void * bad_cast::`vector deleting destructor'(unsigned int)

void * bad_typeid::`scalar deleting destructor'(unsigned int)

void * bad_typeid::`vector deleting destructor'(unsigned int)

void * exception::`scalar deleting destructor'(unsigned int)

void * exception::`vector deleting destructor'(unsigned int)

void * __non_rtti_object::`scalar deleting destructor'(unsigned int)

void * __non_rtti_object::`vector deleting destructor'(unsigned int)

I am now using msvcr70 version 7.00.9955.0 as my default msvcrt in the sys dir and so far so good.

Edited January 10, 201214 yr by loblo

> I am now using msvcr70 version 7.00.9955.0 as my default msvcrt in the sys dir and so far so good.

Me too, only I'm using msvcr71.

Now I've put 7.00.9981 in my sysdir and set:

• 
  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs
  MSVCRT=MSVCR70

After a restart, MSVCR70 is indeed being used by apps instead of MSVCRT (7.1). So KnownDLLs can be used to redirect modules!

I was able to confirm

Neither msvcr70 or msvcr71 cover all of the NT Msvcrt exports.

msvcr70 is missing:
_get_heap_handle

msvcr71 is missing:
_ctype 

but not

void * bad_cast::`scalar deleting destructor'(unsigned int)
void * bad_cast::`vector deleting destructor'(unsigned int)
void * bad_typeid::`scalar deleting destructor'(unsigned int)
void * bad_typeid::`vector deleting destructor'(unsigned int)
void * exception::`scalar deleting destructor'(unsigned int)
void * exception::`vector deleting destructor'(unsigned int)
void * __non_rtti_object::`scalar deleting destructor'(unsigned int)
void * __non_rtti_object::`vector deleting destructor'(unsigned int) 

Both 70 and 71 have ??0bad_cast... and so forth so I don't see how they differ. What tool did you use to interpret the encoded function names (and presumably find the above missing from 71)?

If I make a patch to add a _get_heap_handle stub to msvcr70, we may have a nice solution. Otherwise we can try to get the real NT msvcrt itself working...!

Well, the good news is that substituting "mapi32.dll" for "dwmapi.dll" fixes that particular dependency.

Actually DWMAPI (Microsoft Desktop Window Manager API) has nothing in common with MAPI32 and the substitution only works because RW doesn't seek to import any function from it as can be seen in Dependency Walker so any dll that is compatible with 9x will do (and the same goes with the windowscodecs.dll dependency). And this is unlikely to be an universal situation I guess.

I was able to confirm

Neither msvcr70 or msvcr71 cover all of the NT Msvcrt exports.

msvcr70 is missing:
_get_heap_handle

msvcr71 is missing:
_ctype 

but not

void * bad_cast::`scalar deleting destructor'(unsigned int)
void * bad_cast::`vector deleting destructor'(unsigned int)
void * bad_typeid::`scalar deleting destructor'(unsigned int)
void * bad_typeid::`vector deleting destructor'(unsigned int)
void * exception::`scalar deleting destructor'(unsigned int)
void * exception::`vector deleting destructor'(unsigned int)
void * __non_rtti_object::`scalar deleting destructor'(unsigned int)
void * __non_rtti_object::`vector deleting destructor'(unsigned int) 

Both 70 and 71 have ??0bad_cast... and so forth so I don't see how they differ. What tool did you use to interpret the encoded function names (and presumably find the above missing from 71)?

If I make a patch to add a _get_heap_handle stub to msvcr70, we may have a nice solution. Otherwise we can try to get the real NT msvcrt itself working...!

Well I did export the list of decorated exports of both files from Dependency Walker and compared them each to the list decorated exports of an NT msvcrt with WinMerge and this what I came up with.

Vista and 7's msvcrt seem to have yet more exports which aren't covered by the msvcr7x. Those two at least and perhaps more:

_except_handler4_common

_ftol2

> I am now using msvcr70 version 7.00.9955.0 as my default msvcrt in the sys dir and so far so good.

Me too, only I'm using msvcr71.

Now I've put 7.00.9981 in my sysdir and set:

• 
  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs
  MSVCRT=MSVCR70

After a restart, MSVCR70 is indeed being used by apps instead of MSVCRT (7.1). So KnownDLLs can be used to redirect modules!

The fact that there is no need to restart windows for the changes taking place in this key to apply to newer runs of appications ( ) certainly makes it even more interesting as there is potential for redirection on the fly.

If I make a patch to add a _get_heap_handle stub to msvcr70, we may have a nice solution. Otherwise we can try to get the real NT msvcrt itself working...!

It seems there is only one missing import function for NT msvcrt (in ntdll.dll). B)

Edited January 11, 201214 yr by loblo

> I am now using msvcr70 version 7.00.9955.0 as my default msvcrt in the sys dir and so far so good.

Me too, only I'm using msvcr71.

Now I've put 7.00.9981 in my sysdir and ...

Slightly OT, but do you recall where this version of 'msvcr70.dll' comes from? (Mine is only at version "7.00.9466.0".)

Well, the good news is that substituting "mapi32.dll" for "dwmapi.dll" fixes that particular dependency.

Actually DWMAPI (Microsoft Desktop Window Manager API) has nothing in common with MAPI32 and the substitution only works because RW doesn't seek to import any function from it as can be seen in Dependency Walker so any dll that is compatible with 9x will do (and the same goes with the windowscodecs.dll dependency). And this is unlikely to be an universal situation I guess.

What?! Is this MS playing games with us, or what?

Well, I'll definitely try substituting 'windowscodecs.dll' and testing RW again.

Joe.

About three weeks ago U98SESP3.EXE contained:

6.10.9848.0
7.00.9981.0
7.10.7031.4 

Slightly OT, but do you recall where this version of 'msvcr70.dll' comes from? (Mine is only at version "7.00.9466.0".)

I don't where it comes from but anyway I have now updated it with the one from U98SESP3 Jumper mentioned.

Well, I'll definitely try substituting 'windowscodecs.dll' and testing RW again.

I have version 1.4 of that software which doesn't have those dependencies and doesn't have the pesky richedit line insertion error if used with the right riched20.dll. Let me know in case you don't have it and would like to get it (as it doesn't seem to be available for download anymore).

With R70 or R71 subbed for RT in <system>, DevStudio'97 / VC++5.0 gives me dual GPF's in first DM.DLL (Debuggee Module for WinDbg) and then in MFC42.DLL when I try to run a release build.

At this point, using KnownDLLs to sub in and out SP3 modules on-the-fly became invaluable--great tip, loblo!

• Backing out the RT sub, I reloaded VC5, reloaded the project (IP.33), and clicked 'Run'; no problem.
  
• Subbed RT 6.10.9848.0, reloaded VC5; no problem.
  
• Subbed MSVCP50 version 5.00.7051 for MSVCP50; no problem.
  
• Subbed MFC42.DLL version 6.02.8081.0 for MFC42.DLL; Dual GPF's in DM and MFC42.
  

I read yesterday about MSVC interdependencies and backwards compatibility at fighting-the-msvcrt-dll-hell (See great comment by Andrew on August 9). Remembering that, instead of backing out the MFC42 sub, I also

• subbed R71 back in...and it worked! (R70 also works.)

(Note: this testing was all done with KernelEx 4.52 installed and defaulting to 'off', my normal setup.)

So now I'm worried about M*10,20,30,40, etc. interacting with R70/71 subbed as RT. I haven't actually installed SP3, so this would be a great place for a Newby to jump in, install SP3 then sub in R70/71 for RT and begin testing with older apps. Building a test suit of small apps that exercise various legacy DLL's would be a great help. I'll add this to the Wish List.

I'm having mitigated success using the XPSP2 msvcrt (used in conjunction with the XPSP2 ntdll ).

Msvcrt renamed as msvc9x, ntdll renamed as 9xdll and substituted for ntdll in the renamed msvcrt.

Msvcrt substituted for msvc9x in target test applications.

Works with paint and wordpad but crashes with calc and winipcfg.

An attempt to boot windows with those failed with an error of cmdninst in kernel32.

Using msvcr70 in place of msvcrt, it is now possible to run avidemux 2.5.5:

http://sourceforge.net/projects/avidemux/files/avidemux/2.5.5/avidemux_2.5_r7200_win32.exe/download

The latest version 2.5.6 crashes in libADM_core.dll unfortunately.

Using msvcr70 in place of msvcrt, it is now possible to run avidemux 2.5.5:

What is needed to run Avidemux 2.5.5 ( I have 2.5.3)?

Btw, Xeno knows about ImportPatcher?

Looks like it could be a value add to the KeX project.

Using msvcr70 in place of msvcrt, it is now possible to run avidemux 2.5.5:

What is needed to run Avidemux 2.5.5 ( I have 2.5.3)?

Missing functions imported from msvcrt as you should have guessed.