[loblo]

By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly.

https://skydrive.liv...1303FA52A%21128

Attached are the blank stub.dll with 4 blank export functions and the dnsapi.dll dummy made from it for GTK apps.

Attached File(s)

•  stub.7z (13.25K)
  Number of downloads: 16

This post has been edited by loblo: 09 January 2012 - 04:35 PM

[jumper]

Joe,

KernelEx v4.5 Beta 1 added a stub for HeapSetInformation, so you can leave that function substitution blank.

As for msvcrt.dll, try subbing 71 instead of 90:

I searched my HDD for "msvc*.dll" and came up with 36 hits (including dups). Refining the search to files containing text: "__uncaught_exception" reduced that count to 18 and these seven unique files:

 msvcr70.dll
 msvcr71.dll
 msvcr90.dll
 msvcp70.dll
 msvcp71.dll
 msvcp90.dll
 msvcm90.dll

 r = C Run-time (CRT)
 m = managed (.Net)
 p = C++ Run-time??? (Bonus points to first responder) 

All seven of these missing functions appear to have been introduced in MSVC++ 7.0:

[msvcrt.dll]
__uncaught_exception
___lc_handle_func
___lc_codepage_func
___mb_cur_max_func
__pctype_func
__iob_func
__crtLCMapStringW
__crtGetStringTypeW 

These 8 "functions" (variables probably) can be found in msvc 4 through 7.1, but were removed by 9:

[msvcr9.dll]
??0exception@@QAE@ABQBD@Z=
?what@exception@@UBEPBDXZ=
??1exception@@UAE@XZ=
mktime=
??0exception@@QAE@ABV0@@Z=
??0exception@@QAE@XZ=
??1bad_cast@@UAE@XZ=
??0bad_cast@@QAE@ABV0@@Z= 

I don't have "8" on my system...maybe someone else can check it for these exports.

Quote

Well, my first attempt was thwarted because the name "MSVCR90.dll" was longer than the original "msvcrt.dll". So I copied "MSVCR90.dll" locally as "MSVCR9.dll" and did the module substitution using that name.

Good move--I forgot to count when I suggested it. Because table entries are word-aligned, there should actually be an extra byte available to even-lengthed strings (NULL terminator makes them odd). An additional byte or two can (usually) be stolen from the word-sized hint of the following hint-string pair. (At least one linker out there has a bug that does overlap entries half the time, making optimizing hints impossible without completely bulding the table!)

Since "msvcrt.dll" is even, look for the next beta to support subbing up to: ((length&-2)+1)

p.s. I hope everyone is having as much fun as I am. Thanks everyone!

This post has been edited by jumper: 09 January 2012 - 05:17 PM

[jds]

loblo, on 09 January 2012 - 04:15 PM, said:

By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly.

https://skydrive.liv...1303FA52A%21128

Attached are the blank stub.dll with 4 blank export functions and the dnsapi.dll dummy made from it for GTK apps.

Thanks, loblo. I'm sure that stub will come in handy!

So, you substituted msvcrt.dll with msvrt70.dll (renamed as msvrt7.dll), because the same trick didn't work with msvrt80 or msvcr90. Then you also created a dummy dnsapi.dll. Gotcha.

jumper, on 09 January 2012 - 05:05 PM, said:

As for msvcrt.dll, try subbing 71 instead of 90:

I searched my HDD for "msvc*.dll" and came up with 36 hits (including dups). Refining the search to files containing text: "__uncaught_exception" reduced that count to 18 and these seven unique files:

 msvcr70.dll
 msvcr71.dll
 msvcr90.dll
 msvcp70.dll
 msvcp71.dll
 msvcp90.dll
 msvcm90.dll

 r = C Run-time (CRT)
 m = managed (.Net)
 p = C++ Run-time??? (Bonus points to first responder) 

All seven of these missing functions appear to have been introduced in MSVC++ 7.0:

[msvcrt.dll]
__uncaught_exception
___lc_handle_func
___lc_codepage_func
___mb_cur_max_func
__pctype_func
__iob_func
__crtLCMapStringW
__crtGetStringTypeW 

These 8 "functions" (variables probably) can be found in msvc 4 through 7.1, but were removed by 9:

[msvcr9.dll]
??0exception@@QAE@ABQBD@Z=
?what@exception@@UBEPBDXZ=
??1exception@@UAE@XZ=
mktime=
??0exception@@QAE@ABV0@@Z=
??0exception@@QAE@XZ=
??1bad_cast@@UAE@XZ=
??0bad_cast@@QAE@ABV0@@Z= 

I don't have "8" on my system...maybe someone else can check it for these exports.

Good call. I tried msvcr71.dll, renamed as msvcr7.dll, and it worked!

As for msvcr80.dll, that doesn't have those strange-looking identifiers. (Actually, when I initially saw them, I thought they were just garbage.)

Joe.

[jumper]

loblo, on 09 January 2012 - 04:15 PM, said:

By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly.

https://skydrive.liv...1303FA52A%21128

Attached are the blank stub.dll with 4 blank export functions and the dnsapi.dll dummy made from it for GTK apps.

Wow, great work loblo!

Is KernelEx helping at all? And how did you determine what code to put into the stubs?

GTK is a popular toolkit. Qt is another. If we can get them and .Net working, a lot of apps will start to work.

[jumper]

loblo, on 09 January 2012 - 04:15 PM, said:

By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly.

jds, on 09 January 2012 - 06:05 PM, said:

Good call. I tried msvcr71.dll, renamed as msvcr7.dll, and it worked!

So msvcr70 and msvcr71 seems to be good replacements for msvcrt. Another way to do the substitution is to put a copy renamed to msvcrt directly in the folder the the app and its dll's. And with more backwards compatibility testing, perhaps msvcr71 can be used as a direct update for msvcrt in the <system> folder. (Oops...Did I just volunteer again )

[jumper]

Those using ImportPatcher on 2K, XP, or later might find some registry left-overs in:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping

The PrivateProfileString functions I use to manage .ini files don't use the registry in 9x, but supposedly do in NT.

I plan to move away from the use of .ini files in the near future, so hopefully this problem for NT users will go away soon.

-jumper

This post has been edited by jumper: 09 January 2012 - 07:54 PM

[loblo]

jumper, on 09 January 2012 - 07:19 PM, said:

loblo, on 09 January 2012 - 04:15 PM, said:

By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly.

https://skydrive.liv...1303FA52A%21128

Attached are the blank stub.dll with 4 blank export functions and the dnsapi.dll dummy made from it for GTK apps.

Wow, great work loblo!

Is KernelEx helping at all? And how did you determine what code to put into the stubs?

GTK is a popular toolkit. Qt is another. If we can get them and .Net working, a lot of apps will start to work.

Thanks Jumper.

Of course KernelEx in Windows 2000 compatibility mode is mandatory for running GTK apps.

I did not code anything, I just fired VC6 which I have since years but have never used as I am not a coder, I haven't got a clue about coding, and choose to create a new dll project and I selected the one from the wizard that offered to create some empty skeleton export functions and then I just compiled that. Once this was done I opened the dll with dependency walker and saw there was 4 export function with super weird and rather long names which I hexed to stub1, 2 3 and 4 and this is is the stub.dll I uploaded. After that I just renamed it to dnsapi.dll and hexed two of the export functions to the name of the two functions libgio-2.0-0.dll wants to import from dnsapi and that's all I did and it works.

It was possible and in some case still is possible to replace libgio-2.0-0.dll with an older version from around 2009 which doesn't rely on dnsapi.dll but it is becoming increasingly incompatible with other GTK runtime files it is interdependent with, forcing to replace more dlls with older ones to satisfy it to the point it was hardly workable anymore and in some cases not at all so I am glad I found that little hack as it should give a bit of headroom, along with your msvcrx for mscvrt substitution, for running newer GTK apps.

[loblo]

jumper, on 09 January 2012 - 07:44 PM, said:

loblo, on 09 January 2012 - 04:15 PM, said:

By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly.

jds, on 09 January 2012 - 06:05 PM, said:

Good call. I tried msvcr71.dll, renamed as msvcr7.dll, and it worked!

So msvcr70 and msvcr71 seems to be good replacements for msvcrt. Another way to do the substitution is to put a copy renamed to msvcrt directly in the folder the the app and its dll's. And with more backwards compatibility testing, perhaps msvcr71 can be used as a direct update for msvcrt in the <system> folder. (Oops...Did I just volunteer again )

If I put msvcrt.dll with an application folder it doesn't get used by it, it always uses the one in the system folder. It seems that's because it is listed under the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs registry key. I think this key forces windows to use the listed dlls only from the location that is specified for them and which is the system dir if no full path is specified. I am not sure it is a good idea to override that by deleting some of those entries as to run core system files or quasi core system files such as msvcrt from other locations as when I experimented a bit with that I recall it led to weird problems with standard win9x programs refusing to start. (Well it was with files from Reactos and Wine I tried so maybe it might work with less or no problems with Microsoft files).

This post has been edited by loblo: 10 January 2012 - 01:04 AM

[jumper]

loblo, on 10 January 2012 - 12:49 AM, said:

If I put msvcrt.dll with an application folder it doesn't get used by it, it always uses the one in the system folder. It seems that's because it is listed under the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs registry key. I think this key forces windows to use the listed dlls only from the location that is specified for them and which is the system dir if no full path is specified. I am not sure it is a good idea to override that by deleting some of those entries as to run core system files or quasi core system files such as msvcrt from other locations as when I experimented a bit with that I recall it led to weird problems with standard win9x programs refusing to start. (Well it was with files from Reactos and Wine I tried so maybe it might work with less or no problems with Microsoft files).

I've copied the msvcr71.dll from SP3 into my system folder. I'm shutting SE down for the night, so I'll exit to DOS and make the switch with msvcrt.dll.

In the morning I'll boot with the 'updated' msvcrt.dll and exercize a bunch of apps. If all goes well, I'll try modifying HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs to make the redirection (in the system folder). Perhaps this key can be used to make module subs on-the-fly without needing help from ImportPatcher. That would be great for redirecting delay-load modules.

---

ImportPatcher.32 is now posted.

I spent a couple of hours Saturday creating PEfinder, a tool that scans all files in a given folder and all sub-folders for valid PE headers. A stripped-down version of ImportPatcher, it filters on any DOS/PE/Optional/Directory field I specify (in the src) and outputs a log file with the filename and field value of the matches. (No UI or run-time options.)

Compared to the dozen or so files I had been testing IP with, I was able to test with thousands of files in just a few minutes. And I found three problems:

• Empty files caused CreateFileMapping to fail (like dencorso reported)
  
• 16-bit apps without full DOS header lacked a valid e_lfanew field leading to GPF if random value pointed past EOF
  
• 64-bit modules are PE32+ with longer Optional header, moving Directory table back 16 bytes

Fixes for these issues were ported back to ImportPatcher.32. I also added the bonus character for even-length string names as recently discussed.

[loblo]

By substituting msvcrt for msvcr70 in the Gimp plugin G'Mic I could get rid of the only systematic crash that occurs with it here when using the apply button which is meant to apply the filter on the main image and leave the plugin window open after that. With msvcrt it would crash after application of the filter and now it doesn't anymore which is very cool.

I also tried to make such a substitution for the plugin mathmap which crashes instantly on clicking on some of its scripts/presets entries but in this case it only made matters worst with systematic instant crash in kexbases on lauching the plugin but since it crashes in kexbases it might just well be a KernelEx bug.

Also I think that perrhaps msvcr70 is most compatible with msvcrt as in one instance of the substitutions I made, msvcr71 was missing a function which msvcr70 had.

This post has been edited by loblo: 10 January 2012 - 02:12 PM

[loblo]

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)

[loblo]

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

This post has been edited by loblo: 10 January 2012 - 03:34 PM

[jumper]

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

[loblo]

jds, on 08 January 2012 - 08:29 PM, said:

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.

[loblo]

jumper, on 10 January 2012 - 08:08 PM, said:

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

[loblo]

jumper, on 10 January 2012 - 08:08 PM, said:

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

Quote

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

This post has been edited by loblo: 10 January 2012 - 08:54 PM

[jds]

jumper, on 10 January 2012 - 08:08 PM, said:

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

loblo, on 10 January 2012 - 08:17 PM, said:

jds, on 08 January 2012 - 08:29 PM, said:

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.

[jumper]

About three weeks ago U98SESP3.EXE contained:

6.10.9848.0
7.00.9981.0
7.10.7031.4 

[loblo]

jds, on 11 January 2012 - 01:52 AM, said:

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.

[loblo]

jds, on 11 January 2012 - 01:52 AM, said:

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