Kext: DIY KernelEx extensions

[Goodmaneuver]

Kstub825 ordinal addressing only works up to 1008 for me. See picture.

[jumper]

Thanks, I'll try to reproduce. Looking at the addresses, it might be a problem with Ktree or the way Kstub825 hides the dummy names. What tree branch is displayed in the left window?

 

[Goodmaneuver]

The left window is the same tree display as the middle window which is extensions by API.

[jumper]

Reproduced. Smaller numbers can also fail. 0418 sometimes works, sometimes fails. No workaround yet.

 

[Goodmaneuver]

I should have said before but not only the Core names cannot be changed the order that they are in cannot be changed to that of 4.5.2.

[jumper]

Workaround found: Add an equal number of dummy named stubs.

At most, half plus one of the definitions in each section are converted to ordinals.

Update: Fixed! Coming soon.... Thanks @Goodmaneuver

 

Edited April 18, 2023 by jumper

[schwups]

1. Forwarding problem: Example Uxtheme
Here [UXTHEME.DLL]DrawThemeTextEx=>uvtheme.dll: No forwarding to uvtheme, if original Kex Uxtheme in KernelEx folder is used (message - missing DrawThemeTextEx). Uvtheme.dll = Uxtheme.dll Vista
It works, if I use Uxtheme XPSP3 (sys folder). Then I'm able to run Notepad++ 8.3.3 (with GUI), but not yet really usable.

2. Ordinal support -> possible bug:
It occurs with a large number of ordinals in the same section (here Urlmon). Got message about missing API even though it exists.
Ktree gives on first places # and later 0 (see png). With few entries I have only # and these defs seem to work.

KtreeUrlmon

[Urlmon.dll]
0101=>URLMXP.DLL:
0102=>URLMXP.DLL:
0103=>URLMXP.DLL:
0104=>URLMXP.DLL:  ; IE7 8
0105=>URLMXP.DLL:
0106=>URLMXP.DLL:
0108=>URLMXP.DLL:
0111=>URLMXP.DLL:
0112=>URLMXP.DLL:
0113=>URLMXP.DLL:
0115=>URLMXP.DLL:
0304=>URLMXP.DLL:
0305=>URLMXP.DLL:
0308=>URLMXP.DLL:
0309=>URLMXP.DLL:
0310=>URLMXP.DLL:
0311=>URLMXP.DLL:
0314=>URLMXP.DLL:
0315=>URLMXP.DLL:
0316=>URLMXP.DLL:
0317=>URLMXP.DLL:
0318=>URLMXP.DLL:
0319=>URLMXP.DLL:
0320=>URLMXP.DLL:
0321=>URLMXP.DLL:
0322=>URLMXP.DLL:
0323=>URLMXP.DLL:
0324=>URLMXP.DLL:
0325=>URLMXP.DLL:
0326=>URLMXP.DLL:
0327=>URLMXP.DLL:
0329=>URLMXP.DLL:
0330=>URLMXP.DLL:
0331=>URLMXP.DLL:
0333=>URLMXP.DLL:
0335=>URLMXP.DLL:
0337=>URLMXP.DLL:
0349=>URLMXP.DLL:
0351=>URLMXP.DLL:
0353=>URLMXP.DLL:
0360=>URLMXP.DLL:
0362=>URLMXP.DLL:
0364=>URLMXP.DLL:
0365=>URLMXP.DLL:
0370=>URLMXP.DLL:
0390=>URLMXP.DLL:
0395=>URLMXP.DLL:
0396=>URLMXP.DLL:
0410=>URLMXP.DLL:
CreateUri=>Urlmxp.dll:                 ; n4
CreateIUriBuilder=>URLMXP.DLL:
CreateUriWithFragment=>URLMXP.DLL:
CreateURLMonikerEx2=>URLMXP.DLL:
CoInternetCanonicalizeIUri=>URLMXP.DLL:
CoInternetCombineIUri=>URLMXP.DLL:
CoInternetCombineUrlEx=>URLMXP.DLL:
CoInternetIsFeatureEnabled=>URLMXP.DLL:
CoInternetIsFeatureEnabledForUrl=>URLMXP.DLL:
CoInternetIsFeatureZoneElevationEnabled=>URLMXP.DLL:
CoInternetParseIUri=>URLMXP.DLL:
CoInternetSetFeatureEnabled=>Urlmxp.dll: ;upgrade to ie6+ z3
CompatFlagsFromClsid=>Urlmxp.dll:      ;   IE9
GetIDNFlagsForUri=>URLMXP.DLL:
GetPortFromUrlScheme=>URLMXP.DLL:
GetIUriPriv=>URLMXP.DLL:
GetUrlmonThreadNotificationHwnd=>URLMXP.DLL:
IntlPercentEncodeNormalize=>URLMXP.DLL:
IsIntranetAvailable=>URLMXP.DLL:
QueryAssociations=>URLMXP.DLL:
QueryClsidAssociation=>URLMXP.DLL:
ResetUrlmonLanguageData=>URLMXP.DLL:
ShouldDisplayPunycodeForUri=>URLMXP.DLL:
ShouldShowIntranetWarningSecband=>URLMXP.DLL:

Explanation: URLMXP.DLL = Urlmon.dll IE8

It loads, but got hang by replacing Urlmon IE6.
Manual Update (replacing):
Possible seems to change Menu>FolderOptions>General>WebView to "Use Windows classic folders".
Required is dependent module iertutil.dll (IE8).

IE8 -> still no GUI

[Goodmaneuver]

6 hours ago, schwups said:

Required is dependent module iertutil.dll

You should be able to use Iertutil from Windows 7 up to version 7.0.6000.21396 without any trouble or Vista SP1. They should have a file size of 262kB approximately. Early Vista say LH5728 would be neater with less missing APIs only GlobalMemoryStatusEx of which the Ex can be removed as it only calls this API and not both GlobalMemoryStatusEx and GlobalMemoryStatus. File size 260kB. If there are any other APIs missing that I have not explained then it is because I am using some upgraded modules. Might get back to us on that point if you will.

Edited July 9, 2023 by Goodmaneuver

[Goodmaneuver]

8 hours ago, schwups said:

[UXTHEME.DLL]DrawThemeTextEx

You can use BWC's UXTHEME in KernelEx folder vs 5.1.2599.10 from Windows2000-KB935839-v30 (or similar extended kernel version).

Edited July 9, 2023 by Goodmaneuver

[schwups]

Iertutil of IE 8 gives no trouble here so far I can see. There are other modules of IE 7 or 8 that are causing problems, e.g. browseui, wininet, Urlmon and shlwapi and more. Running IE 7 and 8 isn't very interesting, because they are hardly usable anymore on the internet. The modules that use more modern programs like shlwapi or urlmon are quite interesting.

I'm aware BWC's Uxtheme, but I don't see any benefit at the moment and I just wanted to point out a possible bug.

Supplement: Wininet IE7 seems OK , but gives a message on OS start "wininet expects a newer windows version" and KernelEx doesn't work. After I set Kex mode of wininet from disabled to XP the message is gone and KernelEx works. I think Wininet IE 8 has the urlmon (dependent module) ordinal problem.

 

Edited July 9, 2023 by schwups

[Goodmaneuver]

4 hours ago, schwups said:

I'm aware BWC's Uxtheme, but I don't see any benefit at the moment and I just wanted to point out a possible bug.

Uxtheme should be used in Codesuff Starter, KMPlayer and Opera to name some and it will stay in memory while the programs are running. If not remaining in memory then that module is not being used.

[jumper]

On 7/8/2023 at 2:25 PM, schwups said:

0101=>URLMXP.DLL:

Named api needed after the colon.

 

On 7/8/2023 at 2:25 PM, schwups said:

1. Forwarding problem

KernelEx\KnownDLLs can't be extended yet.

 

On 7/8/2023 at 2:25 PM, schwups said:

2. Ordinal support -> possible bug

Yes. Add dummy names.

 

[schwups]

Goal is that BWC wrappers, windowsXP+ and React OS modules load for forwarding. Xompie modules are mostly unproblematic, but e.g. kernelxp.dll doesn't have widespread API support. I've good progress e.g. with:
Gdi32 - even the win7 file loads
Shell32 - BWC or ReactOS
Urlmon - BWC
Uxtheme - XP or BWC or ReactOS
Netapi32 - BWC
Ntdll - up to win7
Shlwapi - BWC
Advapi - ReactOS
Iphlpapi - ReactOS, but it doesn't support any of the associated API's in my Kext.ini.

Kernel32 - Xompie only
User32 - Xompie only

In the case user32 (ReactOS/BWC/XP) I get prompt message when loading it with Procwin:

Kext Prompt Kstub825
Gdi32.dll:GdiDllInitialize=>xxxxx.DLL:

It doesn't matter which file I use for xxxxx (win7, ROS, Xompie...).

Any Ideas?

I can't add more API packages anymore. I reached Kext limit - I've round about 1500 API defs spread over six ini files now. Kex doesn't load anymore, if I add further eighty defs.

Other Question. Does anyone know why most of the ApiSet Stub DLL files don't load on ME/98?

OK are only
api-ms-win-core-appcompat-l1-1-0.dll 6.2.9200.16384
api-ms-win-core-winrt-l1-1-0.dll 6.2.9200.16384
api-ms-win-core-winrt-string-l1-1-0.dll. 6.2.9200.16384

Oh yes, I've a set of wine5 modules and Procwin does load them all.

Unfortunately, many other construction sites are dormant or have still not brought any progress yet.

[Goodmaneuver]

14 hours ago, schwups said:

I reached Kext limit - I've round about 1500 API defs spread over six ini files now. Kex doesn't load anymore, if I add further eighty defs.

This happens with Kstub825 and what I did was to use 824 and only use 825 where the ordinal definitions were required. I previously had mentioned this but it is good that now that there are 2 testers backing this up.

[Goodmaneuver]

Loading a single module does not make it necessarily usable. The ROS API sets load as an individual module load test because they implicitly load some compatible ME modules but will not work in a practical way because they will explicitly load some incompatible modules, similar here being with other API sets. ME's Ntdll statically links to the fixed API addresses of Kernel32, NT OS versions are incompatible. Gdi32 will load but it needs to link through to the hardware in which Gdi32 of ME's version is already taking this role. ME's Gdi32 has in-use APIs that are also included in the NT modules that would be doubled up. This would not be any good as ME's Gdi32 version will be loaded in almost all programs.

Edited August 8, 2023 by Goodmaneuver