Jump to content

KernelEx 4.5.2


Recommended Posts

  • 2 weeks later...

Just wondering ... has anyone (with the skills/capabilities to build KernelEx) seen this? :

It suggests that the breadth of KernelEx application compatibility can be usefully expanded with a few added stubs.

Joe.

Link to comment
Share on other sites

>It suggests that the breadth of KernelEx application compatibility can be usefully expanded with a few added stubs.

Rebuilding all of KernelEx just to add a stub is overkill. There should be a way to just add a small expansion dll; perhaps this is what the undocumented api was meant to address.

I would like to see an .ini file where users can add "<module name>, <function name>, <return value>, <SetLastError value>" lines that would be loaded by KernelEx and turned into new stubs on-the-fly. (Core.ini can almost do this now....)

I haven't tried building KernelEx yet because I'm still using VC5. My response to loblo' s little hex hacks was to create a tool to automate import table patching. Unfortunately it mutated into a full-blown dependency walker before I could get it released. :(

I'm almost done with minf, so I'll clean up and formally release ImportPatcher next, then get to work on KernelEx.

-jumper

Edited by jumper
Link to comment
Share on other sites

>It suggests that the breadth of KernelEx application compatibility can be usefully expanded with a few added stubs.

Rebuilding all of KernelEx just to add a stub is overkill. There should be a way to just add a small expansion dll; perhaps this is what the undocumented api was meant to address.

I would like to see an .ini file where users can add "<module name>, <function name>, <return value>, <SetLastError value>" lines that would be loaded by KernelEx and turned into new stubs on-the-fly. (Core.ini can almost do this now....)

I haven't tried building KernelEx yet because I'm still using VC5. My response to loblo' s little hex hacks was to create a tool to automate import table patching. Unfortunately it mutated into a full-blown dependency walker before I could get it released. :(

I'm almost done with minf, so I'll clean up and formally release next, then get to work on KernelEx.

-jumper


to be moved:

ImportPatcher currently makes a copy of a PE, creates a dependency log, and patches the copy's OS level if it is greater than the current system's.

My DLLHOOK Program does something similar to what you described but may not be compatable with KernelEx. In addition to the arguments you listed above, you will need to specify the number of calling arguments to properly clean up the stack upon return.

Link to comment
Share on other sites

>>There should be a way to just add a small expansion dll; perhaps this is what the undocumented api was meant to address.

>My DLLHOOK Program does something similar to what you described but may not be compatable with KernelEx.

I found DLLHOOK in your "Large File Emulator" (FILE64) package. The description in readme.txt and the example in dllhook.ini look very promising. If it can patch the Entrypoint Address Resolver to add a new function (not just hook an existing one), we might have a quick solution; if not, an import patcher will also be needed to remap the missing import in the user's PE to an existing (but rarely-used) one. I'll create a dll with a family of generic stubs and test with KernelEx....


>>I would like to see an .ini file where users can add "<module name>, <function name>, <return value>, <SetLastError value>" lines....

>In addition to the arguments you listed above, you will need to specify the number of calling arguments to properly clean up the stack upon return.

Agreed. You wisely mentioned that in the other topic, but I still managed to overlook it! :zzz::blushing:

So others will know what we're talking about:

icon11.gif If the emulated api function uses the Pascal calling convention (most likely), and the stub doesn't clean parameters off the stack as expected, there would be a small, temporary stack leak. If the stub is called enough times, the stack will overflow. Or if the calling function happens to not use a stack frame (for storing local variables), there would be no exit code to restore the stack and return address before it ends.

Link to comment
Share on other sites

>>There should be a way to just add a small expansion dll; perhaps this is what the undocumented api was meant to address.

>My DLLHOOK Program does something similar to what you described but may not be compatable with KernelEx.

I found DLLHOOK in your "Large File Emulator" (FILE64) package. The description in readme.txt and the example in dllhook.ini look very promising. If it can patch the Entrypoint Address Resolver to add a new function (not just hook an existing one), we might have a quick solution; if not, an import patcher will also be needed to remap the missing import in the user's PE to an existing (but rarely-used) one. I'll create a dll with a family of generic stubs and test with KernelEx....

I wrote DLLHOOK long before I wrote the FILE64 Package. It can add new functions just as easily as redirecting existing ones. I was trying to run a XP program in Windows 98. The Program self-checked for modifications, so I could not Patch up the Import Table.

The Demo DLLHOOK Program in the FILE64 Demo is limited to a small .INI File and only redirects KERNEL32.DLL Calls but it should be useful for your testing. Create a DLLHOOK.INI using the following example as a guide:

KERNEL32 EntryPoint1 STUBFILE StubT0

KERNEL32 EntryPoint2 STUBFILE StubF0

KERNEL32 EntryPoint3 STUBFILE StubT4

KERNEL32 EntryPoint4 STUBFILE StubF4

KERNEL32 EntryPoint5 STUBFILE StubT8

KERNEL32 EntryPoint6 STUBFILE StubF8

KERNEL32 EntryPoint7 STUBFILE StubT12

KERNEL32 EntryPoint8 STUBFILE StubF12

....

Create STUBFILE.DLL using the following example:

StubT0 Zero Argument Stub returning TRUE

StubF0 Zero Argument Stub returning FALSE

StubT4 One Argument Stub returning TRUE

StubF4 One Argument Stub returning FALSE

StubT8 Two Argument Stub returning TRUE

StubF8 Two Argument Stub returning FALSE

StubT12 Three Argument Stub returning TRUE

StubF12 Three Argument Stub returning FALSE

....

Link to comment
Share on other sites

Firefox 8.0.1 doesn't crash on exit for me.

Likewise for me. Seems quite stable with KernelEx 4.5.2.

Thanks Xeno86! :)

I installed three Firefox versions 8.0.1, 7.0.1 and 6.0.2 to different folders. The attempt to install PlainOldFavorites with version 7 or 8 failed. After the successful installation of the addon with Firefox 6.0.2 PlainOldFavorites also works with versions 7 and 8. :thumbup

I haven't testet the workaround of Steven W to install PlainOldFavorites Experimental Firefox 7 topic.

Thats great news! And Steven W's workaround ought to work for everyone, too, because it appears that what we have here is just an installer-imposed limitation.

You rock!

Yes it does (work). BTW, the en-GB version I posted in the above thread is already FF8.01 compatible.

Joe.

Edited by jds
Link to comment
Share on other sites

>It suggests that the breadth of KernelEx application compatibility can be usefully expanded with a few added stubs.

Rebuilding all of KernelEx just to add a stub is overkill. There should be a way to just add a small expansion dll; perhaps this is what the undocumented api was meant to address.

I would like to see an .ini file where users can add "<module name>, <function name>, <return value>, <SetLastError value>" lines that would be loaded by KernelEx and turned into new stubs on-the-fly. (Core.ini can almost do this now....)

I haven't tried building KernelEx yet because I'm still using VC5. My response to loblo' s little hex hacks was to create a tool to automate import table patching. Unfortunately it mutated into a full-blown dependency walker before I could get it released. :(

I'm almost done with minf, so I'll clean up and formally release next, then get to work on KernelEx.

Well, I just had in mind that these stubs could be added to the code when convenient, pending the next KernelEx release. However, your suggestion to have an INI file and add new stubs "on the fly" is so much better! What flexibility! :)

You mention only having VC5. I recall asking if VC4 or VC6 would be suitable, but don't think anyone offered an answer. Do you know what the minimum VC version is for building KernelEx?

I might have a play with your Import Patcher, next time the need arises.

Joe.

Link to comment
Share on other sites

With KernelEx 4.5.1 or 4.5.2 installed, DLLHOOK reports: Unknown version of KERNEL32.DLL.

Otherwise (and demo limitations aside), it works great. :) It was very easy to write a DLL and export some stub functions--no DDK needed!

I made modifications to DLLHOOK.INI similar to those above and was able to call a fictitious function in Kernel32 from a test app and redirect it to my DLL. For people who don't use KernelEx, DLLHOOK plus a DLL of stubs might get them by. I imagine this is basically how the Kernel Update Project got started.

Unfortunately, since DLLHOOK doesn't coexist with KernelEx, it can't be used to extend KernelEx as I had hoped. :(

Link to comment
Share on other sites

>You mention only having VC5. I recall asking if VC4 or VC6 would be suitable, but don't think anyone offered an answer. Do you know what the minimum VC version is for building KernelEx?

Building KernelEx requires the Feb 2003 DDK which in turn requires VC6. I do have VC6, but need to dust it off, apply service packs and the DDK before I can start playing with the KernelEx source code.

Link to comment
Share on other sites

Do you know what the minimum VC version is for building KernelEx?

Not sure, but a couple years ago or so I managed to build it under VC6 Express with Windows SDK 2003. Haven't tried that lately, things may have changed.

EDIT:

Just gave it a spin and I got most components compiled, except for kexbasen.dll , kexcontrol.exe and VKrnlEx.vxd . Didn't care to alter the original project settings, I'm too tired right now.

Errors:

Linking...
Creating library Release/kexbasen.lib and object Release/kexbasen.exp
SHBindToParent.obj : error LNK2001: unresolved external symbol __imp__ILFindLastID@4
SHBindToParent.obj : error LNK2001: unresolved external symbol __imp__ILFree@4
SHBindToParent.obj : error LNK2001: unresolved external symbol __imp__ILRemoveLastID@4
SHBindToParent.obj : error LNK2001: unresolved external symbol __imp__ILClone@4
SHCreateDirectoryEx.obj : error LNK2001: unresolved external symbol __imp__SHCreateDirectory@8
SHGetFolderLocation.obj : error LNK2001: unresolved external symbol __imp__SHILCreateFromPath@12
SHGetSpecialFolder.obj : error LNK2001: unresolved external symbol __imp__SHGetSpecialFolderPath@16
Release/kexbasen.dll : fatal error LNK1120: 7 unresolved externals
Error executing link.exe.
-------------------Configuration: kexcontrol - Win32 Release--------------------
Linking...
kexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexUninit
kexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexDbgDumpImtes
kexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexDbgDumpConfigurations
kexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexDbgDumpAppSettings
kexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexInit
Release/kexcontrol.exe : fatal error LNK1120: 5 unresolved externals
Error executing link.exe.
-------------------Configuration: VxD - Win32 Release--------------------
Linking...
LINK : fatal error LNK1181: cannot open input file "vxdwraps.clb"
Error executing link.exe.

Edited by Drugwash
Link to comment
Share on other sites

Bear in mind guys that there is much more to KernelEx than just replaced functions, those VC100 runtime files I hexed won't run if KernelEx is disabled on them even with all the missing imported functions as well as OS and subsystem version in the header "fixed", and with KernelEx enabled it's not good enough to get MFC100.dll to work.

Link to comment
Share on other sites

With KernelEx 4.5.1 or 4.5.2 installed, DLLHOOK reports: Unknown version of KERNEL32.DLL.

Otherwise (and demo limitations aside), it works great. :) It was very easy to write a DLL and export some stub functions--no DDK needed!

I made modifications to DLLHOOK.INI similar to those above and was able to call a fictitious function in Kernel32 from a test app and redirect it to my DLL. For people who don't use KernelEx, DLLHOOK plus a DLL of stubs might get them by. I imagine this is basically how the Kernel Update Project got started.

Unfortunately, since DLLHOOK doesn't coexist with KernelEx, it can't be used to extend KernelEx as I had hoped. :(

Obviously KernelEx Patches the code that DLLHOOK verifies before installing. They both are trying to do the same thing.

I haven't used or analyzed KernelEx so I am not sure what would be needed to make DLLHOOK compatable.

It would probably be easier to add the functionality to KernelEx as it should already be capable to doing it.

In addition, combining Commercial and Freeware Software would be problematical.

I will add a note to my FILE64 Package, on the next update, advising that it is not compatable with KernelEx.

Link to comment
Share on other sites

Bug-Report: Argyll CMS does not work

I just tried to install the open source colour management system Argyll CMS v1.3.5 (designed for Win2k and above) on Win98SE with KernelEx v4.5.101. First it threw illegal instruction errors, but when I manually set all the EXE files KernelEx mode to Win2k or higher, the program seemed to run. (I also installed the "Argyll CMS GUI" extension.) Unfortunately it refuses to communicate with the USB port, so it can not find my Spyder 2 colour measurement probe.

The main problem seems to be that Argyll CMS consists of almost pure Linux code with a small wrapper to communicate with Windoze. The install instruction claimed strange stuff about XDG, which turned out to be a bunch of environment variables pointing to directories found in Linux systems. When I added them in AUTOEXEC.BAT, Win98SE refused to boot with error requester "not enough space for environment" no matter how high I set the "/E:" value of COMMAND.COM in CONFIG.SYS. So I wrote an external BAT file with the following content:

REM Argyll CMS Environment (by CYBERYOGI =CO=Windler)

PATH %PATH%;E:\PROGRA~1\ARGYLL\BIN
SET XDG_DATA_DIRS=E:\PROGRA~1\ARGYLL\XDG\DATA
SET XDG_CONFIG_DIRS=E:\PROGRA~1\ARGYLL\XDG\CONFIG
SET XDG_CACHE_HOME=E:\PROGRA~1\ARGYLL\XDG\CACHE
CD E:\PROGRA~1\ARGYLL

REM spyd2en -Sl E:\PROGRA~1\SpyderTV\cvspyder.dll
REM (execute this once is enough)

ArgyllCMSGUI.exe
COMMAND.COM

After entering "spyd2en -Sl E:\PROGRA~1\SpyderTV\cvspyder.dll" the Spyder 2 driver spyd2PLD.bin is compiled into my "Argyll\xdg\data\color" subdirectory, however no matter what I do, it does not recognize the probe. When I set KEX mode to Win2k, it complains that some USB stuff is not supported. With higher Windoze version settings it simply waits about 10 seconds and reports an error that it can not find the probe. I also tried to manually execute libusb1\Spyd2.inf and have set all related files KEX mode to Win2003 etc.,but the drivers won't install. Also replacing the Spyder 2 driver from system control panel doesn't work.

- Is there a fix to run Argyll CMS with KernelEx?

Can it e.g. use the unmodified cvspyder.dll like HCFR Colorimeter does? My WinDAS-fixed trinitron monitor is too red at medium saturation despite good greyscale and so needs a special ICC profile to get rid of sunburnt looking faces those prevent correct photo editing.

Link to comment
Share on other sites

>It suggests that the breadth of KernelEx application compatibility can be usefully expanded with a few added stubs.

Rebuilding all of KernelEx just to add a stub is overkill. There should be a way to just add a small expansion dll; perhaps this is what the undocumented api was meant to address.

I would like to see an .ini file where users can add "<module name>, <function name>, <return value>, <SetLastError value>" lines that would be loaded by KernelEx and turned into new stubs on-the-fly. (Core.ini can almost do this now....)

I haven't tried building KernelEx yet because I'm still using VC5. My response to loblo' s little hex hacks was to create a tool to automate import table patching. Unfortunately it mutated into a full-blown dependency walker before I could get it released. :(

I'm almost done with minf, so I'll clean up and formally release ImportPatcher next, then get to work on KernelEx.

-jumper

Not wishing to take this thread too far off-topic, I've just tried the Import Patcher on the "signtool.exe" utility from http://www.microsoft.com/download/en/details.aspx?id=8442 (Microsoft Windows SDK for Windows 7 and .NET Framework 4). Image file = GRMSDK_EN_DVD.iso, Path = \Setup\WinSDKTools\cab1.cab, Extract file = WinSDK_signtool_exe_B2E1011D_2F14_488D_A056_C5BD55106409_x86.

Executing 'signtool.exe' by itself (with KernelEx 4.5.2) produces the error :


The SIGNTOOL.EXE file is
linked to missing export MSVCRT.DLL:__uncaught_exception.

Executing with Import Patcher gives a bunch of "Importing from module ..." messages, but not the above message. It also produces a file "signtoo#.exe" which has patches but seems to behave the same as "signtool.exe".

In addition, a log file is produced, from which the following is an extract :


Importing from module: 'msvcrt.dll'
__wgetmainargs: 225 != 142 #
_cexit: 276 != 173 #
_exit: 354 != 215 #
_XcptFilter: 106 != 75 #
exit: 1167 != 607 #
_initterm: 469 != 282 #
_amsg_exit: 257 != 162 #
fgetpos: 1175 != 615 #
__p__commode: 185 != 109 #
__p__fmode: 190 != 114 #
__set_app_type: 210 != 132 #
??1type_info@@UAE@XZ: 17 != 14 #
msvcrt.dll: __uncaught_exception (db) * No match
memmove: 1260 != 686 #
_unlock: 934 != 495 #
__dllonexit: 141 != 88 #
_lock: 578 != 329 #
_onexit: 747 != 403 #
?terminate@@YAXXZ: 55 != 48 #
_controlfp: 295 != 186 #
isleadbyte: 1218 != 651 #
isupper: 1223 != 656 #
_itoa: 561 != 319 #
islower: 1219 != 652 #
__badioinfo: 133 != 84 #
__pioinfo: 207 != 130 #
_fileno: 367 != 226 #
_lseeki64: 587 != 337 #
_write: 1096 != 555 #
_isatty: 478 != 287 #
??0exception@@QAE@ABQBD@Z: 9 != 7 #
?what@exception@@UBEPBDXZ: 57 != 50 #
??1exception@@UAE@XZ: 16 != 13 #
fwrite: 1201 != 636 #
setvbuf: 1287 != 708 #
fflush: 1173 != 613 #
ungetc: 1341 != 749 #
fputc: 1185 != 623 #
fgetc: 1174 != 614 #
malloc: 1246 != 679 #
_callnewh: 274 != 172 #
setlocale: 1286 != 707 #
msvcrt.dll: ___lc_handle_func (7f) * No match
msvcrt.dll: ___lc_codepage_func (7d) * No match
msvcrt.dll: ___mb_cur_max_func (80) * No match
abort: 1142 != 586 #
ungetwc: 1342 != 750 #
msvcrt.dll: __pctype_func (ce) * No match
__crtLCMapStringA: 138 != 87 #
msvcrt.dll: __iob_func (93) * No match
__mb_cur_max: 176 != 100 #
msvcrt.dll: __crtLCMapStringW (8b) * No match
wctomb: 1390 != 778 #

Now two questions come to mind :

1. Is there a way to pass command line parameters to "signtool.exe" when using the Import Patcher?

2. Should the "signtoo#.exe" application run OK (not exhibit the same missing import/export message)?

Joe.

PS. A really neat way to access content from ISO files (such as GRMSDK_EN_DVD.iso) is with the freeware MagicDisc driver (build 105 is the current version for W9X). Just be sure to (1) Configure the virtual drive letter(s) as desired via the MagicDisc context menu and (2) Disable its/their "Auto insert notification" option in Device Manager.

Edited by jds
Link to comment
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.
×
×
  • Create New...