Goodmaneuver

Using KernelEx Verify.exe make sure the message window says "KernelEx has been successfully installed and is now enabled for all applications". If not reinstall 4.5.2 with it enabled. The Singularly Listed functions do not need stubbing. Using 4.5.2 + Kstubs with later KernelEx.dll, these Kstub entries work. Do not confuse SL with LS, use entries as shown. GetSystemWow64DirectoryW=>KERNEL32:GetWindowsDirectoryW HeapQueryInformation=>KERNEL32:HeapSize InitializeSListHead=>KERNEL32:MapHModuleLS InterlockedFlushSList=>KERNEL32:UnMapLS InterlockedPopEntrySList=>KERNEL32:FreeLSCallback InterlockedPushEntrySList=>KERNEL32:AllocLSCallback QueryDepthSList=>KERNEL32:GetLSCallbackTemplate

Kstubs825 does not behave properly as it confuses User32 with Uxtheme as see in the Kstub07.zip. Evidence in upload zip and Ktree11 picture. As can be see in picture that there is no reference to Uxtheme for UnregisterTouchWindow and Kstub824 in the log zip redirects all 3 Touch Window functions from their rightful caller :- User32. KSTUB07.zip

Kstub825 is good for one INI but when strung together with many INIs the amount of kB that can be placed in each INI has to be reduced. Roughly 8k each for 7 linked INIs. To make more redirects possible I have used Kstub824 up to the last one which is Kstub825 so that I can use the ordinal redirection in the last one. Kstub823 was better in certain respects as well as at the time it allowed redirecting back to MSVCRT as I explained before. The new features are much preferred though. Perhaps a Word sort lstrcmpiW would be better than a Bubble sort because of the special characters like under scores _ .

It must be that Advapi32 redirects are not logging but when I redirected in system KnownDlls Advapi32 to Advapi86 then Advapi86 is logged. The redirects for Advapi32 are working though. (Tests done on DDR3 machine only.)

Once Kstub is set to not log then set to log again it does not log again. Going from logging [#prefs#] Log=1 to Log=0 rebooting then trying to reinstate the logging with Log=1, it does not reinstate the logging. Kstub01 never returned to logging but Kstub05 did after several reboots.

There is no trouble with the large total number of active - in RAM API functions when using new Kstub825 as I have tried it without making a mistake. Thank you. I am not sure as to what you mean? By making ExKernel available for programs that only work as seen below with MIN setting cover all of your statement? [MIN] contents=std desc=Minimal load help (subsystem + KnownDlls) [MIN.names] KERNEL32.K32_NtStatusToDosError=Kstub01 KERNEL32.NtCreateFile=Kstub01 KERNEL32.NtFsControlFile=Kstub01 KERNEL32.NtPowerInformation=Kstub01 KERNEL32.NtQueryInformationFile=Kstub01 KERNEL32.NtQueryInformationThread=Kstub01 SHELL32.ILFree=kexbases.0 SHELL32.SHCreateShellItem=kexbases.0 SHELL32.SHParseDisplayName=kexbasen.0

I thought I have explained it several times. SumatraPDF did not work with 2K settings. It needs at least a 2K setting because of VerSetConditionMask and VerifyVersioninfo APIs are called. With Core.ini 24 DCFG1 works for VerSetConditionMask and VerifyVersioninfo in Kernel32. I made up another mode so that SumatraPDF will work on eBooks as you asked. Remember you changed the naming of DCFG1 to that of 4.5.2 and your [DCFG1] behaves as explained above. The (Verify Version) comment in the sheet is named BASE in the registry from [BASE] in my CORE.ini. Important: the renaming of Core.ini modes from original 4.5.2 should not be done and their order should not be changed. If more modes are to be added they should be placed at the bottom of Core.ini. If not adhering to this and settings of these modes are changed your OS will change behavior in an unexpected unpreferred way.

Starting with this link https://msfn.org/board/topic/157173-kext-diy-kernelex-extensions/?do=findComment&comment=1228984 then you said to investigate why and place BASE names into DCFG1 but it should have been place from NT2K into DCFG1. What is the significance of five times max per issue by the way? It is the addition of KERNEL32.GetVersionExA=kexbases.5 that is the trouble. I assume you have downloaded CORE_8.zip. In this Core.ini the mode displayed by the sheet will be BASE (Verify Version) Verify Version I am using on Explorer and the addition of that one line KERNEL32.GetVersionExA=kexbases.5 not only stops the SPDF it also stops MSSQL server 7. I made Verify Version equivalent to 2K here GDI32.GetCharABCWidthsI=kexbasen.0 GDI32.GetRandomRgn=kexbases.0 GDI32.GetTextMetricsA=kexbases.0 GDI32.GetWorldTransform=kexbases.0 GDI32.ModifyWorldTransform=kexbases.0 GDI32.SetGraphicsMode=kexbases.0 GDI32.SetMapMode=kexbases.0 GDI32.SetWorldTransform=kexbases.1 KERNEL32.CreateIoCompletionPort=kexbases.0 NTDLL.LdrUnloadDll=kexbases.0 NTDLL.RtlGetVersion=kexbases.5 NTDLL.RtlVerifyVersionInfo=kexbases.0 KERNEL32.GetVersion=kexbases.4 KERNEL32.GetVersionExW=kexbases.5 KERNEL32.VerSetConditionMask=kexbases.0 KERNEL32.VerifyVersionInfoA=kexbases.0 KERNEL32.VerifyVersionInfoW=kexbases.0 and Explorer using Verify Version and MSSQL server is working and SumatraPDF3.2 is set to Verify Version and it still works with 2K settings but add KERNEL32.GetVersionExA=kexbases.5 and no good. I then just had KERNEL32.GetVersionExA=kexbases.5 by itself in Verify Version setting and I get Explorer made an error in unknown.

Verify Version is probably not worded real well but it was discussed in Kext: DIY KernelEx extensions where I first posted this info about DW but it was shifted here to a new topic.

I did not practice what I preached when making the proposed CORE.ini. Windows XP SP2 needs to be WINXP mode. Must be done and I will again upload a better CORE_8.zip. It is similar to latest CORE.ini but does not change original mode naming.

GetCharABCWidthsI was inherited from DCFG1 so it makes sense that GetCharABCWidthsI=kexbasen.0 needed to be added; I forgot again. If not added it made the green KEX initiating error in DW log when GetCharABCWidthsI was called and was missing. The green errors means that KEX was not working/initiating. It depends on the order of std,kexbasen,kexbases,kstub01,kstub02,kstub03,kstub04 what DW green initiating error comes first in the DW log.

It did not matter about that module, it was more of an experiment. It was MSXML from WIN8 and I am using latest WIN7 MSXML which registers no problems. I will send in a failure of an unexpectancy soon as I am working on the concept that because Verify Version needed GetCharABCWidthsI=kexbasen.0 added then perhaps kexbasen.0 and kexbases.0 is not default and will need to be added throughout where applicable. It might be a while though. I will do my best. .

After mentioning all this, if the sequence of the std,kexbasen,kexbases,kstub01,kstub02,kstub03,kstub04 in CORE.ini is altered then ADVAPI32 error returns and won't be good again if placing CORE.ini back as it was.

https://msfn.org/board/topic/183930-dw-has-trouble-hooking-advapi32-and-gdi32-on-ddr34-systems-with-many-kernelex2016-app-settings/?do=findComment&comment=1235306 This link is to the above post of mine. It turns out that it is quite specific I accidentally made a duplicate of [KERNEL32] RtlCaptureContext=>MEDLL: (MEDLL is my renamed RADMIN32. The MEDAL option). It is necessary to do this to stop the DW ADVAPI32 error. In [MEDLL] I have RtlCaptureContext=>KERNEL32:GetTreadContext. It is not necessary to have the the [MEDLL] redirect there to get the ADVAPI32 error to go away though. I tried for hours to see if ADVAPI32 error would go away but it did not. It went away when I placed in the duplicate of RtlCaptureContext redirected to MEDLL. It went away straight away after reboot. The GDI32 CRC read error is unrelated though and still occurring. The original fix did both fixes on 2 different builds at that time. Since then the build I am working on is a bit more complex.

I deleted many lines in Ksub01 at the top. They were only locale name to LCID and LCID to locale name functions. I then opened several programs but no new different APIs were listed in Kstubs. When you said we have to find definitions, is that really true, or can we use Kstubs for redirection like I am doing. KSTUBS.zip

The log file for Kstub01 has not updated since 8th January 23 so this is suspect. It is 64kB in size. The other ones have updated 13th January :- today.

It was early days with this and one other thing that has to be ensured. If redirecting to RADMIN32 from KERNEL32 then the redirects have to be redirected to a renamed RADMIN32 otherwise these DW errors come back. The MEDAL idea is discussed in DIY KernelEx extensions. I think this statement is correct but I was confused when a module would not pass the register test which prompted me to alter this post. I might as well print the register results from DW. KernelEx stopped working while registering.

No Kstub log does not show it.

I am please to say that I have fixed most of the issues discussed here. The GDI32 CRC error and ADVAPI32 export table errors with DW have been fixed with the Kstub entry for [ADVAPI32.DLL] QueryServiceConfig2W=>RADMIN32:QueryServiceConfigW I did not want to send QueryServiceConfigW API back to ADVAPI32 just in case both QueryServiceConfig2W and QueryServiceConfigW were called at once. The 100% Commit Charge still exists in Process explorer. The testing was done on ASUS MSA78LE.

I have looked into it several years ago and it is when SHLWAPI goes to load URLMON then there is a problem. There is little to no benefit from running IE7 over IE6. JSCRIPT can be updated as shown in the IE6 upload. MSXML3 also can be updated to recent version which is not shown in the upload. IE6 modules are an integral part of the OS and if a second version is to be run along side then it could cause severe problems. IE7 would need to be safe mode compatible. I was foolish to mention 2454 GDI32 as it would not run along side ME's version even though it loads. The 2454 UXTHEME has only one function missing in ME's GDI32 anyway and it is accounted for by KEX. I am running IE7 executable as shown in the upload but it does not make any difference. Trust BWC's Windows2000-KB935839-v30e-ex86-extendedkernel 2019 updates for IE6 as I have done. In the proposed CORE.ini I sent in, the Verify Version setting needs the other two 2K missing APIs namely GDI32.GetCharABCWidthsI=kexbasen.0 and probably NTDLL.LdrUnloadDll=kexbases.0. When registering a module with missing GetCharABCWidthsI it knocked out KernelEx completely so that is why if Verify Version is to be used more wide spread the two BASE.names mentioned should be included. Once adding GetCharABCWidthsI the module registered no problems. I have changed CORE_8.zip to have the updated BASE.names as mentioned above.

Yes and no on that. You see as well as RAD32 I also have these module redirects in system KnownDLLs to RADMIN32. API-MS-WIN-CORE-RTLSUPPORT-L1-2-0 API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0 API-MS-WIN-SECURITY-LSALOOKUP-L2-1-0 API-MS-WIN-SECURITY-LSALOOKUP-L2-1-1 API-MS-WIN-SECURITY-LSAPOLICY-L1-1-0 API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0 API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0 API-MS-WIN-SERVICE-WINSVC-L1-1-0 API-MS-WIN-SERVICE-WINSVC-L1-2-0 BROWCLI NETAPI NETRAP SAMCLI SAMLIB SRVCLI WKSCLI Redirecting to a module named RADMIN32 with Kstubs does not work for me. Obviously if those KnownDlls above are missing an API for a particular module then the MEDAL option is to be applied. Unicows; depending on what you have in mind; if the first part of the CTRAS API 's names are ignored then CTRAS vs 0.2.0.3 is an alternative. For example GetCharABCWidthsI=>CTRAS:WAPI_CTGetCharABCWidthsI. CTRAS was distributed with MSreader. There is no trouble though with UNICOWS or Kexbasen showing up for me. Folder path mapping is a problem showing up with JAVA and it occurred a long time ago in KEX but not 4.5.2. It would help if I find out just when it occurred. It occurs win Windows 7 32 bit and it makes a folder path in Users\*login name*\ folder. I tend to think that the NT folder path conversion APIs should not be stubbed. Yes but KMPlayer modifies the skin with a variable color control. Their browser uses Windows system but changes color scheme to dark. Even an error message will be dark theming. Their alpha transparency does not work though. A renaming of GDI32 from 5.1.2454 will load and the 2 theme entries of UXTHEME 5.1.2454 namely PaintMenuBar and CalcMenuBar could be stubbed. I am using modern ROS UXTHEME feeding ROS 2011 era as base and this has the first use of Kstub825 as an ordinal redirect. UXTHEME is loaded with Mozilla browser, Internet Explorer and therefore Explorer plus KMP, PotPlayer ecectera WMP9 but not 7. I have incorporated UXTHEME from 5.1.2223. The HTML upload will show what modules in use that load with IE6. An insight into what is happening at the moment. horizontal.htm

I have said a few things about RADMIN32 and Kstub redirects before; some things now can be disregarded. What works 100% is if you directly link to RADMIN32 using hex editor when there are no missing imported APIs. If there are some missing RADMIN32 export entries, then you use a renamed RADMIN32, say we use MEDAL, and use KexStubs to redirect the missing APIs to MEDAL. These redirections seem to have no restriction on what client redirect module you choose. Do not use system redirects in registry KnownDlls to MEDAL. I have RAD32 redirected in system KnownDlls to RADMIN32. This is so that shorter named APIs can be replaced with RAD32 when there are no missing APIs. The registry then redirects RAD32 to RADMIN32. There is no need to worry about a solution for ResolveDelayLoadedAPI; ResolveDelayLoadedAPI=>KERNEL32:BeginUpdateResourceW seems to work.

You are wright it does not download any more. I am sorry for not trying to download it again; I downloaded it yesterday.

It is probably best to use ROS WindowsCodecs of 2011 era as it loads better without any missing imported APIs from OLE32 and is equivalent to Vista SP1 6001. 2017 6003 vs would not register. It makes a difference to KMPlayer 4.06's preferences menu where the different KMP themes change appearances.

I would suggest it be accurate? That should work then but VXDs are not necessarily compatible between the Win98 and WinME I have found.