Kext: DIY KernelEx extensions

[Goodmaneuver]

New discovery: if the Core.ini string for kstub is kstub823 then Kstubs will still work if the kstub.ini and kstub.dll are named kstub824. It seems the OS looks at the first 7 characters on a new install. This can be altered though in the setup; if you are going to alter INFs then this 7 character sighting can be changed but SFNs right throughout as well need changing. Must be changed within the install CABs.

Edited December 12, 2021 by Goodmaneuver

[Goodmaneuver]

@jumper

23 hours ago, Goodmaneuver said:

Dependency Walker profiles good with Msvcrt Windows 2000 Std heap settings and also Base std heap.

Note Well : - This quote is correct but DW does not profile when it is set itself to BaseN nor Win2000 std for examples and that is why MSVCRT needs to be set disabled.

Investigating : -Testing with MSVCRT set to Win2000 std, DW itself set on Win2000 std causes huge problems so I set DW BaseN for testing. This may emulate the Base enhancement errors. The results are not helpful as DW can not hook ImageHlp.

Help :- If wanting MSVCRT to run in BASE then ImageHlp can be made use PerlCrt which is almost the same as Pncrt and probably Pncrt vs 5 and set PerlCrt to disabled. That works to boot but Dependency Walker still has trouble with MSVCRT left in BASE when profiling with Depends set to other modes. The end log results with DW set to BaseN and profiling MPlayer2.exe, hope it helps.

00:00:00.361: DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\tools\bench & diag\dependency walker\DEPENDS.DLL" called by thread 1.
00:00:00.368: DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\tools\bench & diag\dependency walker\DEPENDS.DLL" returned 1 (0x1) by thread 1.
00:00:01.848: DllMain(0x7D000000, DLL_PROCESS_ATTACH, 0x00000001) in "c:\me\system\MSVCRT.DLL" called by thread 1.
00:00:01.852: GetProcAddress(0xBFF60000 [c:\me\system\KERNEL32.DLL], "InitializeCriticalSectionAndSpinCount") called from "c:\me\system\MSVCRT.DLL" at address 0x7D0077FF and returned 0x84D79E08 by thread 1.
00:00:01.857: DllMain(0x7D000000, DLL_PROCESS_ATTACH, 0x00000001) in "c:\me\system\MSVCRT.DLL" returned 0 (0x0) by thread 1.
00:00:01.890: Exited "c:\program files\windows media player\MPLAYER2.EXE" (process 0xFFFA66AD) with code -1 (0xFFFFFFFF) by thread 1.

Edited December 13, 2021 by Goodmaneuver
Big mistake

[Goodmaneuver]

@jumper; I made a mistake in registry I believe as evidence seems that way. There was no problem having MSVCRT set Win2000std as far as adding devices. The devices would have all installed and the next module to load probably caused KernelEx.dll to not be able to start. I had *\MSVC*.DLL set BASEN when I looked, sorry about that.

Edited December 13, 2021 by Goodmaneuver

[Goodmaneuver]

Just to be clear, it does not appear that MSVCRT is supposed to call InitializeCriticalSectionAndSpinCount as seen with the same settings for DW and MPlayer2 and MSVCRT set disabled picture. DW is set BaseN and MPlayer2 set in follower mode. This is the same as before when posting DW log. Profiling with DW is working with MSVCRT set disabled. Other programs will be affected as well so MSVCRT must be disabled. To Jumpers credit there are no red errors and no function calls in Depends when Depends is set on DCFG1 or in follower mode. Explorer in advanced build of mine that I got going on KEX25 is set DCFG1. There are no calls in Depends showing except DllMain the modules and returning 1. Oleaut32 should not call SetCriticalSpinCount when using correct KernelEx modes nor should UnhandledExeptionFilter be called.

Edited December 14, 2021 by Goodmaneuver

[schwups]

IE9stubs.ini:

On 9/27/2021 at 7:45 PM, jumper said:

Unnamed (ordinal) functions and data variables are not yet supported.

Jumper, have you made progress? I don't think that I can run IE8/9 without support for the ordinal functions.

 

[jumper]

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

 

[schwups]

Thanks

[Goodmaneuver]

On 8/20/2021 at 8:05 PM, Goodmaneuver said:

If I have Definition named MSVCRT with the same module renamed back to MSVCRT and KnownDLLs MSVCRT redirect deleted, I get a red screen of death

I have Kstubs working with KEX25 now. MSVCRT as a definition is fixed with K25. The above quote is now redundant, no longer applicable. EDIT but might be unique to one build to which I have not KEX25 running just yet.  What is new and what had me fooled is that there no longer can be a definition for RADMIN32. By definition I mean [RADMIN32] in kstubs.ini.  EDIT This is unique to one build and I cannot fix it so far and not related to Kex25.

Because there was an inherit problem with CORE.ini, ie DCFG1 VerSetConditionMask=kexbases.0 when it should not have, I got rid of the inherit=( ) except where it was not truly overwritten by any changes and simplified CORE.ini for experimenting. Resulting effect was DCFG1 VerSetConditionMask=none now is correct and so any AppSettings DCFG1 relying on VerSetConditionMask=kexbases.0 had to be changed to NT2K. (NT2K suits my oversimplified CORE.ini) I am sure there will be more new discoveries, I have posted as soon as possible.

CORE_3.zip

Edited December 20, 2021 by Goodmaneuver
added picture

[Goodmaneuver]

22 hours ago, jumper said:

To test, put kexbasen and kexbases on opposite ends of contents= and increase the number of dummy plugins between them.

Tested; my system will not run without KernelEx. If Kernelex is not running then Ktree does not run either. You cannot use dummy plugins it will stop KernelEx.

 

Edited January 27, 2022 by Goodmaneuver

[jumper]

So what is the new limit? Six?

And cut out the misinformation. Triple check your text and edit before posting.

 

[Goodmaneuver]

I have gone up to 22 and OS is still OK. I think that is a fair test for now, why break it? My advice for others who are willing to try this is to increase number of plugins slowly for the registry's sake. I have used the most challenging build for this experiment.

5 hours ago, jumper said:

cut out the misinformation

What have I posted recently that you have issues with. You should not be reserved about it because I do not know what the misinformation is.

Core_6.zip

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

[Goodmaneuver]

The operating system will need to adjust to the changes. I found that jumping ahead with too many new plugins after 12 meant that I had slight issues which I have encountered before with this build and it is associated with the registry which is operating in the RAM along with all other active modules. My comments should be respected and other members also.

2 hours ago, jumper said:

And you still have not confirmed that more than four actually work.

Why do you not believe me? Try to get the programs I have shown in the pictures to work without KernelEx. First one is PotPlayer which is using Flash.ocx of which 10 is inadequate and will stall program. Flash is not essential though. There are other KernelEx requirements for PotPlayer and last post shows WinMerge 2.14 which needs Msvcr90 and it is a case of keeping the upload file size to a minimum. What more proof do you want? Ktree11 works in Safe Mode but if after making changes to CORE.ini or Kstubs and there are mistakes or what ever the reason that Ktree does not work afterwards then forget about rebooting as KernelEx will not work after reboot. Schwups can you back this statement up by exceeding the Kstub character limit and then open Ktree.

2 hours ago, jumper said:

So that means all the text of your previous post is wrong.

No, you are joking right?

Edited January 28, 2022 by Goodmaneuver
Was thinking wxHexeditor's version. Just a slight version error on WinMerge.

[schwups]

Today, I tried two more plugins:

--- No OS override ---

[BASE]
contents=Kexstubs,stubs,Kstub824,std,Kexbasen,Kexbases,kexvista
desc=Base enhancements (api fixes + extensions)

1. Test: Splitted my ini in three parts (A-I, J-N, O-Z)

2. Test: Basically my ini and these for 360EE and IE9

As far as I can tell these plugins work. I've captured them all with DependencyWalker when profiling different programs.
Does it make sense to split the ini so that we have one ini for every dll? I think, only some more make sense. Some more and smaller ini files can, for example, simplify troubleshooting in many cases. It could be useful for two or three programs.

I haven't tested anything related to "exceeding the Kstub character limit" again so far.

[Goodmaneuver]

12 hours ago, schwups said:

Does it make sense to split the ini so that we have one ini for every dll?

If you are referring to my Core_6.ini where you see one definition module in each Kstub. This was done to stretch out the number of plugins. I had 20 DLLs having redirected function calls.

 

12 hours ago, schwups said:

Test: Splitted my ini in three parts (A-I, J-N, O-Z)

If this means that you have made up 3 Kstub,inis then you also need three matching Kstub824.dlls renamed to suit the ini names. Your contents= does not show this though.

 

12 hours ago, schwups said:

I haven't tested anything related to "exceeding the Kstub character limit" again so far.

If you exceed the character number limit and then open Ktree there will be a blank window showing nothing for Ktree and KernelEx will not be working. So when you then open a new program requiring KernelEx, the program will not work.