jumper

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 )

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.

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

Probably a delay-load import. IP doesn't handle those yet. Try Dependency Walker--it should find it and report if it is a standard or delay load type. Sounds like a wide-char mapi library. Try doing a preemptive module substitution with mapi32.dll or tmapi.dll; then look at what functions are reported missing.

ImportPatcher.31 is now posted. It has the fixes I promised dencorso. I've found enough discrepancies concerning function hints between the documentation, various guides, and what Dependency Walker reports that I've decided to disable the hints and binds features as a needless distraction at this time. The code is still in there, so it'll come back in time. The [Missing modules] section that only appeared if a module couldn't be found is now named [Module substitutions] and is always present. Substitutions for module and function names are now made before the dependency is checked, allowing for more creative patching options. There is still a constraint, however, that substituted names must not be longer than the name they replace. As for a more compelling new feature, I was able to alter the ending message box to provide a 'Retry' option. Now we can check the log file, edit the ini file, then click on 'Retry' to start another pass without having to reinvoke IP. (We can still click 'Cancel' to exit and then reinvoke later if we want.) The next step is now obvious: a dialog box interface with checkboxes for the Yes/No parameters and edit boxes for the text fields, and buttons that can be labelled beyond MessageBox contraints. No more hunting for the ini or log files! After that, I'll fully parse the headers and essentially relink much of the file if necessary to allow substitution of longer names and even additional modules. This will allow individual function calls to be redirected to stub libraries or even custom DLL's.

The previous version was dotNet4.0--even more recent. Because KernelEx won't always be up-to-date with the latest demands of new software, it would be nice to know if ImportPatcher can help fill the void. To that end, it would be great if you could test the dotNet4.0 version with the msvcrt->msvcr90 replacement I proposed. This might also really help out those who don't use KernelEx. TIA, jumper.

I'll try, but I don't have any OS later than SE to test on. Good error reporting like you provided here will be important. My WinMainCRTStartup function simply returned without calling exit or ExitProcess. This works in SE; apparently not in 2K+. I've added ExitProcess now. The Debug message is mine and indicates that CreateFileMapping (part of the file-mapping sequence of calls) failed. I have located and fixed a minor (SE didn't mind) error in one of the protection flags. I'll also add GetLastCallError support to the error reporting. Despite forcing CreateFileMapping to fail when in patch mode, I was unable to reproduce the error loop. I'm testing IP.31 builds now and much code has been cleaned up since IP.29. I'll trace the old code in my best simulator (sleep on it) in a few minutes.... ImportPatcher is currently designed to function recursively. A stack overflow is the expected result of a runaway loop. The slow speed is likely the result of DW managing a huge amount of text in the log window. A (hitherto) undocumented feature of ImportPatcher is that the text of all message boxes, log file entries, and any error messages are also passed to OutputDebugMessage(). Running IP in a debug environment such as DW allows viewing of these messages. If IP is looping endlessly (until the stack overflows) the DW log window should be filling will huge amounts of text.

Well, I found a version "7.0.6002.18005 (lh_sp2rtm.090410-1830)" on a Vista machine, dated 2009/4/11. However, although this version only reported "[Need patching? ... msvcrt.dll=Y (OS subsystem)" in ImportPatcher (with 'Walk dependencies=N'), after being patched for the OS subsystem, it looked like a descent into DLL dependency hell. All seven of those functions are supported in MSVCR90.dll in the package VC_R_9X.EXE at MDGX. If (anyone is) not running KernelEx, patch MSVCR90.dll with this function replacement: [KERNEL32.dll] GetSystemWindowsDirectoryW=GetWindowsDirectoryW Put MSVCR90.dll in the same folder as signtool.exe or in <windows> or <system>. Then add to signtoo#.ini: [Missing modules] msvcrt.dll=MSVCR90.dll msvcrt.dll=MSVCR9#.dll ;or this if you don't rename after patching This should fix the MSVCRT.DLL issues. If signtool has futher dependency problems, post the full .ini file this time (in a 'spoiler' box if large). * Note: ImportPatcher.29 and .30 syntax (may change in other versions) *

Great ideas! KernelEx is crucial to most of our wishes, so I'll add it as a separate category. It is already accumulating many wishes of its own. Java is one I had thought of but completely forgot. Printer/printing is another--hardware and software issue here. I'll review all discussion and update the Wish List tonight! -jumper

Since writing the COMCTL32.DLL example the other day, the patched COMCTL32.DLL has been running on my system with no problems. >It's quite amazing, really! Thanks, but it's really just an exercise in learning how to parse the various header structures in the Portable Executable file format. Documentation and guides are hard to find and incomplete, but I keep stumbling onto more of them each week! IP.30 is undergoing final testing and includes unbinding of broken links. On the drawing board for function substitution is redirection to another module: [uSER32.dll] _missing=KERNEL32.SetLastError and possibly module insertion: [uSER32.dll] _missing=stubs.T16 >Substituting another function or stub for '__uncaught_exception' might {not} be acceptable to the calling app. If not, ... I could have written "might or might not be", but chose to simplify and wrote "might be". When dealing in fuzzy logic, "not" sometimes becomes optional or even meaningless! >>Also, a *#.* copy of every file that is walked is created, including system DLLs (only useful if you're trying to fragment your HDD!). >Does this relate to the "Link to copies=Y/N" option in the INI file? Would this also require "Walk dependencies=Y"? No and Yes! IP.27 would open for R/W a copy of every file it analyzed (whether walking dep's or not) so that it could analyze and patch in one pass. Unfortunately, it didn't delete unneeded copies. Copying every file also made it slow (and loud). "Link to copies=Y/N" determines whether an app or dll references the original or patched dependency. Naming this option to something understandable has been problematic! Y = patch reference to refer to patched copy of dependency needed if dependencies are patched and the (patched) app is to be directly executable N = continue to refer to original needed if patched files are intended to be installed over originals For patched system files an installer is needed (or the file must be copies by hand in DOS). Creation of an .inf will also be tied to this option some time soon! >>>1. Is there a way to pass command line parameters to "signtool.exe" when using the Import Patcher? >>IP.28 reads parameters from an .ini file that can be edited between passes. >I think that ImportPatcher.27 gave the impression that it would load and execute a file, while satisfying missing dependencies. Since that doesn't seem to be the case, my earlier question was null and void. I misread the question about command line parameters, but now understand. Executing the patched app is a possible future feature and parameter passing would be an important design issue. Perhaps a "[Parameters] App command line parameters=" line in the .ini?

That's great news! Now folks using KernelEx will soon have the option to start creating files larger than 4GB... ...errr, does this mean I have to start adding large file support to all my programs? ...

I made better progress today trying to build some of the sub-projects with VC5 than I previously did several months ago. ApiLog and Core are both close to building after numerous small mods to paths, pragmas, link options, pointer casts, etc. Use of ApiHook in a special build is not what I had in mind, but might work. I'm looking for a method that will allow non-programmers to add stubs to the standard version of KernelEx by modifying an .ini file. For instance, Core.ini contains the section: [WIN98.names] KERNEL32.GetVersion=kexbases.1 KERNEL32.GetVersionExA=kexbases.2 KERNEL32.GetVersionExW=kexbases.2 I'd like to be able to add: MYDLL.SomeFunction=stubs.5 to allow SomeFunction in MYDLL.dll to be replaced with function ordinal 5 in Windows\KernelEx\stubs.dll (stubs.dll is an actual dll built ten days ago containing a family of stubs along the lines of rloew's suggestions). Well, that's it for now. I'll resume trying to get more of KernelEx to build tomorrow.

>...can it improve video playback, streaming and gaming. KernelEx doesn't improve -- it enables playback, streaming and gaming for many applications that otherwise refuse to either install or run on Win98/ME. >By the way, anybody need help let me know. Im here to contribute the best I can and also learn some things too. Welcome to the Win9x sub-forum, mrsk565. We look forward your contributions as we attempt to grow our favorite platform's fan-base together! -jumper

2012 MSFN Project Wish List Hardware and drivers WDM hardware driver repackager / installer partial project: minf create 9x driver from any WDM driver support: .inf, .msi, Inno, custom installers... [*] WDM api extender: Walter Oney's WDMSTUB.SYS project topic [*] Support for hard disks with 4 kilobyte native sectors ATA, SATA, USB or otherwise connected [*] Hyper-threading / Multi-core support [*] Hybrid flash-backed RAM drive compression! flash write combining FAT in RAM EWF-like [*] AGP RAM disk AGP / PCI video texture memory non-XMS so no virtual address space load My 128MB Predator could add 120MB RDD to 256MB system! System and software MSVCRT update with NT functions project discussion MSVCR70/71 used as replacement MFC42.DLL and possibly others must also be replaced Need someone(s) to install SP3, sub in R70/71 for RT and begin testing with older apps. [*] Modern web browsing Firefox, Opera, Kmeleon custom builds, more Kex support IPv6 support and compatible firewall [*] "New style" Java plug-in support [*] Flash dynamic loader / switcher NPSWF32.dll / flash*.ocx stubs that could load 9/10/11 based on URL Browser independent [*] System DLL rebaser / binder DLL's from a variety of sources probably do not all load at their preferred bases Relocated modules cannot be swapped out! KernelEx Better XP SP2+ stability All printing functions / issues project topic solution for apps using PrintDlgExA and PrintDlgExW [*] Support for: Opera 11, 12 Firefox plug-ins: 20-20/Ikea, ... Acrobat Reader 7.09 Adobe Air version 1.5 Post your wish, or discuss any of these. If a new wish is seconded, I'll add it to the list above. Links to existing or new projects will be included....

Sorry for the delay, slhk. I've been looking for and finally found a good example. Back on 5/5/2003, I installed Microsoft Active Accessibility which updated COMCTL32.DLL from version 5.00.2614.3500 to 5.00.2614.3600. Version 5.00.2614.3500 is part of IE5.0 and imports bound links from other IE5.0 DLLs. Version 5.00.2614.3600 is part of IE5.0.1 and is bound to other DLLs that didn't get updated, causing loading delays. I copied v3500 to my temp folder and named it COMCTL32aa.DLL. I copied v3600 to my temp folder and named it COMCTL32bb.DLL. I analyzed each of these files in ImportPatcher.29 (by dragging them to a shortcut on my desktop). The .ini file for v3500 shows an empty list under "[Need patching? (do not edit)]" -- this indicates no errors found: COMCTL32a#.ini [ImportPatcher.29 - Intructions] ;Edit parameters and replacement strings and run ImportPatcher again. <= [Parameters] Mode: (A)nalyze or (P)atch=A Walk dependencies=N Link to copies=Y Fix function hints=Y [Need patching? (do not edit)] The .log file for v3500 shows good binds with KERNEL32.dll and ADVAPI32.dll, but bad binds with GDI32.dll and USER32.dll. This indicates GDI32.dll and USER32.dll were build to match a different KERNEL32.dll and also need to be fixed. COMCTL32a#.log The .ini file for v3600 shows "R:\COMCTL32bb.DLL=Y (function hint)" under "[Need patching? (do not edit)]" -- this indicates that some ordinal link hints need fixing: COMCTL32b#.ini [ImportPatcher.29 - Intructions] ;Edit parameters and replacement strings and run ImportPatcher again. <= [Parameters] Mode: (A)nalyze or (P)atch=A Walk dependencies=N Link to copies=N Fix function hints=Y [Need patching? (do not edit)] R:\COMCTL32bb.DLL=Y (function hint) I edited the Mode parameter to read "Mode: (A)nalyze or (P)atch=P" and reprocessed in ImportPatcher. The .log file then confirmed lots of patched mismatched function ordinal hints: COMCTL32b#.log To confirm the problems had been fixed, I renamed to COMCTL32b#.DLL file to COMCTL32.DLL and reanalyzed: COMCTL3#.ini [ImportPatcher.29 - Intructions] ;Edit parameters and replacement strings and run ImportPatcher again. <= [Parameters] Mode: (A)nalyze or (P)atch=A Walk dependencies=N Link to copies=Y Fix function hints=Y [Need patching? (do not edit)] Nothing needs patching and: COMCTL3#.log all ordinal hints match actual function ordinals! The last step was to backup the original v3600 in Windows\System and replace it with the newly patched COMCTL32.DLL.

Thank you for reporting that Argyll CMS v1.3.5 does indeed run on Win9x with the help of KernelEx set to Win2k mode. The rest of your post, however, is the "no Win9x drivers for my hardware" problem with a twist: the app won't use the standard drivers, wants to use its own, but doesn't support Win9x. If KernelEx 4.5.2 doesn't support all the advanced functions needed by the Win2k drivers, you'll need to find a Win9x driver solution. I recommend reading this Argyll Installation on Microsoft Windows page for info on using alternative drivers; and this libusb-win32 page for the last version to support Win9x. If you need more help with the hardware drivers, please start a new topic. I have many more ideas that should help, but would be way off-topic here!

Good idea, loblo! Upcoming beta29 will now do that for us: [KERNEL32.dll] DecodePointer=DecodePointer EncodePointer=EncodePointer [Missing modules] MSVCR100.dll=MSVCR100.dll It also adds a similar option for missing modules. For example, this works quite well: [Missing modules] MSVCR100.dll=MSVCR90.dll

Looks like MS has added a new function to a venerable support file. Substituting another function or stub for '__uncaught_exception' might not be acceptable to the calling app. If not, try locating a version of MSVCRT.DLL that includes this function. ImportPatcher.27 was my last internal build back on Nov 10, 2011, before development took a break. Those are debug messages--I never expected to release that build as a sneak-preview. IP.27 patches the OS version and creates a dependency log that is somewhat readable. The resulting #.exe file will only be loadable if the OS version was the only load error. Also, a *#.* copy of every file that is walked is created, including system DLLs (only useful if you're trying to fragment your HDD!). Try again with IP.28; or better yet, with IP.29 later tonight. IP.28 reads parameters from an .ini file that can be edited between passes. That is the goal. If you supply valid replacement functions, the patched copy should get past the system loader.

ImportPatcher Enable a new executable to load with old DLLs or on an older OS. ImportPatcher.41.7z debugging DLL: IPstub.zip Drugwash's API Parameter Count v1.0.1.0 Features:Analyzes a program's OS subsystem and Import requirements Walks (recurses through) all dependencies (optional) Creates #.log file with detailed results Creates #.ini file for controlling patching step Patches OS subsystem if needed Substitutes for any import modules and functions, missing or not Patches hints for better performance (optional) Hint support disabled pending design review Supports all Portable Executable (PE) files (apps, dll's, ...) Works in four steps: Set parameters [ Analyze ] Edit DLL filename and API strings [ Patch ] Suggested usage:Create a shortcut to ImportPatcher in your Windows SendTo folder Send files to it using the right-click context menu. Notes:All file patching is done on copies. Filenames containing '=' are incompatible with the use of an .ini file. Please rename. If module MSVC*#*.DLL is reported missing, try replacing it with 'MSVC*71*.DLL. History:

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

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.

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

>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

A while back I almost asked if someone had written a tool to make these checks and do any needed patching--then realized it would be tantamount to volunteering! ← minf - minimize an INF file

minf (minimize INF file) latest beta: minf.04.exe Done:Convert UTF-16 (Unicode) to UTF-8 (ASCII)Abbreviate lengthy section namesRemove comments and white spaceMinimize variable namesTo do:Minimize section namesRemove non-9x sectionsCreate 9x sections from 2k/XP if missingWhy?To fix poorly tested Win9x installer information (INF) files.Enable 2K/XP WDM drivers to possibly work in 98/SE/ME.Addresses issues raised by jds and jaclaz in:← Driver compatibility issues for W9XSuggested usage: Create a shortcut to minf in your Windows SendTo folder and send INF files to it using the right-click context menu. minf.01.exe implements these first two features: Convert UTF-16 (Unicode) to UTF-8 (ASCII) If the first two bytes of the file are FF FE or FE FF, those two bytes plus every other byte thereafter are removed.Abbreviate lengthy section names All section names are checked for length. Any over 28 characters are abbreviated to 10..16 and all references patched.minf.02.exe adds support for: Remove comments and white space All comments and (non-quoted) white space are removed and new-lines reduced to a single line-feed.minf.03.exe adds: Minimize variable names All variable names are reduced to the range A-Z,A0-ZZ and references patched. A 75KB test file was reduced to 50KB!minf.04.exe adds: + If any section names are squashed to 28, the original size is now reported. - Files not terminated with a line feed are now handled successfully. To do: Minimize section names It should be possible to do something similar to variable names, but decoration parsing will be required.Remove non-9x sections Once I fully understand section naming and decorating conventions, it should be possible to completely remove sections not needed by Win9x.Create 9x sections from 2k/XP if missing If no Win9x sections exist, an attempt could be made to adapt a 2K or XP section.