Giant2011 Posted December 6, 2011 Posted December 6, 2011 Just installed Opera 11.60 on Windows 98SE Everything worked fine.
jds Posted December 19, 2011 Posted December 19, 2011 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.
jumper Posted December 20, 2011 Posted December 20, 2011 (edited) >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 December 25, 2011 by jumper
rloew Posted December 20, 2011 Posted December 20, 2011 >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.-jumperto 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.
jumper Posted December 21, 2011 Posted December 21, 2011 >>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! So others will know what we're talking about: 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.
rloew Posted December 21, 2011 Posted December 21, 2011 >>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 StubT0KERNEL32 EntryPoint2 STUBFILE StubF0KERNEL32 EntryPoint3 STUBFILE StubT4KERNEL32 EntryPoint4 STUBFILE StubF4KERNEL32 EntryPoint5 STUBFILE StubT8KERNEL32 EntryPoint6 STUBFILE StubF8KERNEL32 EntryPoint7 STUBFILE StubT12KERNEL32 EntryPoint8 STUBFILE StubF12....Create STUBFILE.DLL using the following example:StubT0 Zero Argument Stub returning TRUEStubF0 Zero Argument Stub returning FALSEStubT4 One Argument Stub returning TRUEStubF4 One Argument Stub returning FALSEStubT8 Two Argument Stub returning TRUEStubF8 Two Argument Stub returning FALSEStubT12 Three Argument Stub returning TRUEStubF12 Three Argument Stub returning FALSE....
jds Posted December 21, 2011 Posted December 21, 2011 (edited) 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. 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 December 21, 2011 by jds
jds Posted December 21, 2011 Posted December 21, 2011 >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.
jumper Posted December 21, 2011 Posted December 21, 2011 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.
jumper Posted December 21, 2011 Posted December 21, 2011 >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.
Drugwash Posted December 21, 2011 Posted December 21, 2011 (edited) 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.expSHBindToParent.obj : error LNK2001: unresolved external symbol __imp__ILFindLastID@4SHBindToParent.obj : error LNK2001: unresolved external symbol __imp__ILFree@4SHBindToParent.obj : error LNK2001: unresolved external symbol __imp__ILRemoveLastID@4SHBindToParent.obj : error LNK2001: unresolved external symbol __imp__ILClone@4SHCreateDirectoryEx.obj : error LNK2001: unresolved external symbol __imp__SHCreateDirectory@8SHGetFolderLocation.obj : error LNK2001: unresolved external symbol __imp__SHILCreateFromPath@12SHGetSpecialFolder.obj : error LNK2001: unresolved external symbol __imp__SHGetSpecialFolderPath@16Release/kexbasen.dll : fatal error LNK1120: 7 unresolved externalsError executing link.exe.-------------------Configuration: kexcontrol - Win32 Release--------------------Linking...kexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexUninitkexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexDbgDumpImteskexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexDbgDumpConfigurationskexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexDbgDumpAppSettingskexcontrol.obj : error LNK2001: unresolved external symbol __imp__kexInitRelease/kexcontrol.exe : fatal error LNK1120: 5 unresolved externalsError executing link.exe.-------------------Configuration: VxD - Win32 Release--------------------Linking...LINK : fatal error LNK1181: cannot open input file "vxdwraps.clb"Error executing link.exe. Edited January 16, 2012 by Drugwash
loblo Posted December 21, 2011 Posted December 21, 2011 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.
rloew Posted December 21, 2011 Posted December 21, 2011 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.
CyberyogiCoWindler Posted December 21, 2011 Posted December 21, 2011 Bug-Report: Argyll CMS does not workI 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\BINSET XDG_DATA_DIRS=E:\PROGRA~1\ARGYLL\XDG\DATASET XDG_CONFIG_DIRS=E:\PROGRA~1\ARGYLL\XDG\CONFIGSET XDG_CACHE_HOME=E:\PROGRA~1\ARGYLL\XDG\CACHECD E:\PROGRA~1\ARGYLLREM spyd2en -Sl E:\PROGRA~1\SpyderTV\cvspyder.dllREM (execute this once is enough)ArgyllCMSGUI.exeCOMMAND.COMAfter 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.
jds Posted December 26, 2011 Posted December 26, 2011 (edited) >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.-jumperNot 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 islinked 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 January 5, 2012 by jds
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now