jumper

ImportPatcher.41 - Find and fix dependency problems

142 posts in this topic

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)

0

Share this post


Link to post
Share on other sites

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

Edited by loblo
0

Share this post


Link to post
Share on other sites

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

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...!

0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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

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 by loblo
0

Share this post


Link to post
Share on other sites

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

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.

0

Share this post


Link to post
Share on other sites

About three weeks ago U98SESP3.EXE contained:


6.10.9848.0
7.00.9981.0
7.10.7031.4

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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).

0

Share this post


Link to post
Share on other sites

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! :yes:

  • 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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.