jumper

> for the registry's sake There you go again. And you still have not confirmed that more than four actually work. Ktree doesn't have a limit so it only shows what's in core.ini, not if KernelEx can process it correctly. So that means all the text of your previous post is wrong.

Do not use any CRT that is not readily available to everyone. Anything else hinders development of KernelEx. A final release version for end users must work with the standard libraries and/or those from common USP's. If there are functions missing from those libraries that you have not reported, please report them now .

So what is the new limit? Six? And cut out the misinformation. Triple check your text and edit before posting.

Ktree shows what's in core.ini, not if it works. KernelEx still works even if not all the plugins do. So more than four plugins has yet to be properly tested.

I don't know what the current plugin limit is. I raised all the array size constants, but never actually discovered what was causing the limit. The code all looked good. Haven't looked at it lately. To test, put kexbasen and kexbases on opposite ends of contents= and increase the number of dummy plugins between them. When an app that needs both stops working, we're past the limit. Also test Ktree; there is no fixed limit, but there appears to be a 300 char limit on the retrieved contents= string value. Character count in stubs.ini needs to include white space, but nothing not a section name or inside a section. Best estimate is to save from first section to eof, then look at the filesize. All bets are off when sections are not all fully sorted. These aren't.

Reserve custom memory ranges in: My Computer -> Properties -> Device Manager -> Computer -> Properties -> Reserve Resources If you can't boot in safe mode, exactly how many megabytes of low memory can be safely used?

A simple debugger and other Nirsoft app monitoring tools

The log file shows all imports, not just the missing ones. It has lots of details for experts. Feature creep has made it ever harder to understand, so just ignore it. You should also ignore the ini file, a historical legacy, and just use the dialog box interface. Just fill in the name of a replacement function after each equal sign. For example: GetTickCount64=GetTickCount Then click Patch. For functions missing from Kernel32, try DebugBreak if research doesn't turn up a better option.

Look for a 5.10.6324 or 6230. And of course the Realtek driver didn't work, you have an IDT (Integrated Device Technologies). Use DM with the MUC IDT packages. BTW, did Snappy tell you what audio hardware it thinks you have?

Use Device Manager to update the driver by browsing to the inf. It'll tell you if the inf contains information about your hardware (or not). Nothing to fear.

Search MUC for "idt audio xp" 12 results from 2007-2011.

The formatting or filesystem might not be XP-compatible. Try above, then reformat. Try higher OS or LiveCD Linux. Maybe another driver is available or perhaps someone has developed an updated USB driver for XP.

Did you mean "Programs"? Don't use $OEM$. For an executable, just drag it there and you should be prompted. Otherwise, create a shortcut elsewhere then move it by dragging. Or right-click on the Start button and select one of the Open options.

Kexbases.25 has been fixed. Original post with updated full .25 package. Thanks to schwups for instinctively suspecting the Dbghelp support via Lz32. It was causing shared library Kexbases to have a dependency on Imagehlp, a non-shared library. Those functions have been removed from Kexbases.25 and will be added to Kexbasen.26. And thanks to everyone for your patience and help in getting this resolved.

I like your new core.ini simplification to not use inherit=, as use of contents= seems to break the inheritance of .names. You should add ME to the descriptions because you removed the native-OS checks. I never did like the use of .names.98 and .names.Me. It doesn't take into account DLL updates, packs, or installable components. I'm working on a new DLL-version-based check. [DCFG1] is missing some Secur32 and User32 =std entries. Functionality is lost without them. But without inheritance, .0 entries are no longer needed! Legacy modes are being fazed out (for over two years now), so please don't use any of the 4.5.2 short mode names anymore. They will be deprecated soon. All modes will soon require a GetVersion setting. Modules not set to a valid mode will be evaluated and assigned a mode. Defaults and inheritance will probably all be going away. Begin adapting by not using the Don't... and Override... advanced options except for brief tests. Continue using Don't... on Explorer.exe until the transition is complete.

Not seeing Hopes and Dreams in the list. What number? And what is the OST?

No builds in over 3-1/2 years. Looking at it now. Okay, almost done. Sort will now also have to compare apples to ordinals. Figuring that out now. Then some testing....

Thanks, that's great. Now others can see what files should go where to get it running.

Wow! Both FF45 and FF52 running on Windows 98se. Please run MiniSnap and post the module list so we can see what version of each file is loaded and from what location. Thanks.

=- deletes the entry. Msvcrt 6/7 should also work in Base (with the heap enhancements). Revert any kexstubs.ini definitions and find for both 6 and 7 the last combination of files that worked with Base. BTW, nobody should be using kstub24.ini directly. It is a sample file with new instructions and examples. On ME, the dbghelp->lz32 redirection should not be used. It is for 9x only. 0x80 is the definition valid flag.

Clicking on the button causes the error a second time?

Or 2021/12/02. Or "20211202" at the end of a filename for versioning.

I can reproduce. A second, high priority, Explorer process is created when Opening Containing Folder from search results if Launch...in a separate process is enabled.

Right. The opcode is 59hex, the instruction is POP ECX. But we're not interested in that. Stay focused and tell me about the call.

Did you spot my typo? The address in the stack dump we are investigating is actually BFA01F2A. If that is (hopefully) a return address, we want to know what the call was. Run Winproc16 on any system. Select MPREXE in the process list on the left. If Kex is even partially running, you will see KernelEx.dll in the module list on the right. If not, select process PROCWIN; find and load KernelEx.dll with File>Load a Dll; move aside but do not dismiss any popups. Double-click on Kernelex.dll for module details. In the code tab, do we see what we were hoping for?