KernelEx 2022 (Kex22) Test Versions (4.22.26.2)

[schwups]

Goodmaneuver, sorry, I still haven't fully tested your workaround. I see that was a lot of work! I have taken other approaches and I wasn't able to run Kex25 with Kexbases25 on ME so far.

I spent hours working on the core.ini today. Jumper, I also tried to overwrite the Api's of the changelog (Kexbase 4.5.2016.25 notes). The main problem may be related to "Lz32.ImageNtHeader". The page fault doesn't occur, if I set "Lz32.ImageNtHeader" in the core.ini to none, but then ME runs without KernelEX only (no messages). Is this API somehow required to start KernelEX 25?

A second abnormality: A runtime error message after removing "LZ32.MakeSureDirectoryPathExists=none" - "Lz32.ImageNtHeader=none" remained in the core.ini. Result: One program couldn't start because of this error.

 

Lz32.ImageNtHeader -> ImageNtHeader (for Dbghelp)
Lz32.MakeSureDirectoryPathExists -> MakeSureDirectoryPathExists (for Dbghelp)
Lz32.SymCleanup    -> SymCleanup    (for Dbghelp)
Lz32.SymGetOptions -> SymGetOptions (for Dbghelp)
Lz32.SymInitialize -> SymInitialize (for Dbghelp)
Lz32.SymSetOptions -> SymSetOptions (for Dbghelp)

For what is this support of these API's necessary? What's the point? All these Api's are already supported by the original DbgHelp file of ME.

Edited December 8, 2021 by schwups

[MiKl]

@schwups. Thanks for your post. That was indeed helpful and I had a lot of clean-up in knowndll's to do !! Hadn't touched KernelEx settings in ca. 2 years ...

 

@jumper. After removing all these ReactOS entries in knowndll's I only left the ones from XP that I think should not cause any problems.

However, I am now also in the already by schwups and goodm reported situation that KernelEx 25 does not load properly/work.

Maybe this helps because I think tyukok mentioned that he has no issues on his 98SE install.  Thanks

[Goodmaneuver]

@jumper; I have all modules working with WinMe now. I have fiddled with Core.i25 and what makes it work I think is the order in which the first few mode listings order is set. See https://msfn.org/board/topic/157173-kext-diy-kernelex-extensions/?do=findComment&comment=1209284

 

[schwups]

Goodmaneuver thanks, now I've ME running with Kex25 - Kexbasen and Kexbases. I simply changed my favoured kexmode BaseSN on Msvcrt.dll (7.0.9981.0) to "Base enhancements standard heap". It can be so simple. Jumper, I don't think, that it's intended, but rather an issue, that Basesn and probably higher modes on Msvcrt.dll lead to this error. Sure, that need more checks and a fresh KernelEX installation to verify this. This KernelEX registry key is very old here . Indeed, the problem appears to be primarily related to MSVCRT. The original MSVCRT registry entry in KernelEX 4.5.2 settings.reg is: "*\\MSVCRT.DLL"=- ([HKEY_LOCAL_MACHINE\Software\KernelEx\AppSettings\Flags]). Not sure what =- means. I guess due to my experiment with the fresh installation of ME and KernelEx the setting on msvcrt have to be changed on Win ME.

[jumper]

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

 

[Goodmaneuver]

2 hours ago, jumper said:

Msvcrt 6/7 should also work in Base (with the heap enhancements).

No; with my advanced build and new build Base does not allow boot. BaseS works but BaseN does not. I vouch for Schwups that BASE standard heap works and I hope that he can vouch for me that Windows 2000 standard heap also works.

2 hours ago, jumper said:

Revert any kexstubs.ini definitions and find for both 6 and 7 the last combination of files that worked with Base.

MSVCR90 will need more than base to work, NT40, but 6,7,8 can be operated disabled.

2 hours ago, jumper said:

0x80 is the definition valid flag.

Do you mean 0x80000000 or 0x00000080? I have not seen 0x80000000 before.

Edited December 12, 2021 by Goodmaneuver
added new build

[schwups]

3 hours ago, jumper said:

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

Thanks

MSVCRT also works in Bases and Win2000 standard heap, not in Basen and Basesn mode.

Edited December 12, 2021 by schwups

[Goodmaneuver]

22 hours ago, jumper said:

the last combination of files that worked with Base

Well if you mean other files and before KEX25 then there was no problems really with BASE setting and only has occurred since KEX24. With Kexbases25 everything that needs Msvcrt seems to not work with Msvcrt on BASE setting and rejects sharply. It is almost impossible to Ctr+Alt+Del interrupt the processing on the new build. I did it once but then you can not run a new program as the Rundll32 has problems :- The Rundll32 fault.

Schwups don't forget to say BASE does not work BaseSN may imply that Base enhancements doesn't work but it is a little different.

Dependency Walker profiles good with Msvcrt Windows 2000 Std heap settings and also Base std heap but not if Depends is set to a mode setting itself like BaseN or Win2Kstd.

Edited December 13, 2021 by Goodmaneuver
added more info

[schwups]

The complete list for Win ME/KernelEX25:

Working modes (MSVCRT):

Disabled

BASEstd

BASES

MIN

WIN2Kstd

Not working modes:

default

Base

BASESN

BASEN

WIN95 up to WIN10A (except WIN2Kstd)

all legacy modes

 

98SE: Quick short tests produced no errors with all Kex modes on MSVCRT.

Edited December 12, 2021 by schwups

[schwups]

10 hours ago, jumper said:

.... and find for both 6 and 7 the last combination of files that worked with Base.

KernelEX24 (Kexbasen/Kexbases): I haven't noticed any problems in this regard, but I have certainly not tried all of the modes. I am sure that default, Base and Basesn modes are OK. As we said, the problem apparently starts with Kexbases25.

[Goodmaneuver]

In the process of getting KEX25 going I have disabled just about all system common in use modules. The scripting error character 17 line 348 in Sysroot.htt is because Oleaut32 for 2K needs a KEX NT setting to display the pie graph though as I mentioned here at top of page 51 the pie graph and shortcuts can be displayed with Oleaut32 disabled if done as explained. The main reason prompting this post is that when executables are disabled then the rest of the modules it calls are also disabled. KernelEx.dll is not invoked. This works out if all modules can be disabled and MIN can be tried and usually works if this is a problem. If another module needs a KEX setting to operate then disabled on the program executable is not an option. I tested this with Process Explorer disabled and Powrprof.dll vs 5.0.809.2300 which needs an NT setting. This results in Process Explorer having total failure to load. This is how KernelEx operates when disabled so what is important then is the 'Override settings of individual modules' when KEX selected disabled is going to be enforced so perhaps the Override setting box could be blanked out when on disabled selection but operator must be aware that override of modules will occur on the exe. ( Powrprof and Powercfg.cpl of this version is obviously no good as Process Explorer's usage in safe mode is then stopped and so is Control Panel. ) Oleaut32 2K does not have Sysroot.htt issues when Kexbases5 is used or I have used NT4 server update 4519 Oleaut32 which can be set disabled.

Edited December 21, 2021 by Goodmaneuver
Added more info

[jumper]

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.

 

[Goodmaneuver]

6 hours ago, jumper said:

But without inheritance, .0 entries are no longer needed!

So zero is a/the default setting : - good to know, the NTDLL.LdrUnloadDll will be in use at all modes except disabled and MIN with the uploaded CORE_4.ini. NTDLL.LdrUnloadDll being 0 would be a preference for me as opposed to none. I do not use 95 to ME settings. It is ME or 98 OS that we are using and it does not make a lot of sense to use 95 to ME settings when default works. I have not found a need for std for Secure32 and User32 and also I prefer to have VerSetCondionMask.0 + VerifyVersionInfo be 0 as opposed to none as this works faultlessly also. The naming suits the KEX installer at the moment and changing names is inconvenient for the operator. I have a lot of fiddling to go but it looks KEX25 is not going to work as it stands on WinMe for some programs that did work with KEX24. Rundll32 remains in RAM for NVCPL.dll when it should not as other Rundll32 started DLLs; Rundll32 does not remain in RAM. (more to this : - short story) This is not a new phenomenon though. The zero lines can be removed then from this newer updated CORE.ini. Have you got the WS2K3 SP2 version numbers as CORE.25 suggests they are for SP1.

CORE_4.zip

[schwups]

I am for improvement and I will probably not miss the legacy modes.

[jumper]

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.