Jump to content

KernelEx 2022 (Kex22) Test Versions (4.22.26.2)


jumper

Recommended Posts


@Miki see here and here. Use Dependency Walker to check for missing export functions & edit string within the DLL that is described using a HEX editor or similar, one is described on page 41 last post, oddly this post does not show in my profile. I would like to know what requirements are necessary for VLC 2.28 to run? The auxiliary Msvcrt what version was it and how did you have it implemented?
 

Edited by Goodmaneuver
Link to comment
Share on other sites

  • 1 month later...

KexBases23 has introduced an error in the LAVFilters-0.70.2-16.exe install (see image). OK with KexBases22.

There is an alternative to Msvcr80 31113 or 40209 as msvcrt. BlackWingCat's Msvcrt from Windows2000-KB935839-v22l-x86-ENU or any other 2K vs works if Ntdll > NtClose is linked to Gdi32 > DeleteObject. Tested as system substitute, Miro Video Converter & VLC3 all OK. There is only one application that I know of that needs depreciated _ctype which was an early ROS Explorer.exe. If _ctype function is needed then BlackWingCat's msvcrt is an alternative. Another good thing is its image base memory address 0x77B4000 does not clash with other modules except Mydocs.dll. Sadly the wrapped Msvcrt.dw7 vs from Dx9W2kFx.zip did not work. Msvcrt was wrapped with Msvcr80 to provide a better Msvcrt with more functions. EDIT > It does work using BWC's Msvcrt.


NB I have updated one other build from 4.5.120 to KEX22 & flash 11_6_602_180 still works. Also Riched20 vs 14.0.7155.5000 is working on all applications using it. ( Not quite, I did not realize at the time I had a separate copy of different versions of Riched20 in WinWord and Maxthon ) Some of my other builds require vs 5.50.99.2070 to work. (Certain menus & save options are corrupted with later Riched20 versions where GetGlyphIndicesW function appeared, & KEX is not to blame, I believe it is in the registry). MakeHuman1.1.1 also exited without error with NVOpenGL still set disabled and still working. So it looks like KEX settings are determining differing outcomes.

LAV70.png

Edited by Goodmaneuver
Fixed important error for new readers.
Link to comment
Share on other sites

> KexBases23 has introduced an error in the LAVFilters-0.70.2-16.exe install (see image). OK with KexBases22.
Profile it and check the debug logs to see what changed that might have caused the problem. I can't do much without details. Remember to try alternate compat. modes.

> There is an alternative to Msvcr80 31113 or 40209 as msvcrt.
Msvcrt.dll is a known problem. Do not use Msvcrt80.dll as Msvcrt.dll ! Use 6.10.9848.0, 7.00.9981.0 or 7.10.7031.4 instead. Then KernelEx can provide the additional API's needed.

> if Ntdll > NtClose is linked to Gdi32 > DeleteObject
NtClose currently calls CloseHandle: "NtClose function...Deprecated. Closes the specified handle. NtClose is superseded by CloseHandle." DeleteObject is not the same thing.

> Also Riched20 vs 14.0.7155.5000 is working on all applications using it. Some of my other builds require vs 5.50.99.2070 to work. (Certain menus & save options are corrupted with later Riched20 versions where GetGlyphIndicesW function appeared, & KEX is not to blame, I believe it is in the registry)
I currently use 5.30.23.1200. More research on Riched20 and Riched32 is needed.

Link to comment
Share on other sites

Msvcr70 or Msvcr71 any vs should not be used due to missing functions. Msvcr80's development changed significantly & dotnet's 31113 & 40209 Msvcr80 work faultlessly as Msvcrt. I am surprised you have not investigated/tried it. CloseHandle does not work, I tried it. I got my information from Microsoft web site and NtClose closes object of any type and decrements count very similar to DeleteObject. I am posting this message using the Msvcrt 7.0.3790.4341 as system file which is available from BlackWingCat's web site.

Edited by Goodmaneuver
Link to comment
Share on other sites

Lav70 install error, does not happen with Lav69. Lav69 installer works with XPsp3 or above mode and is OK with KexBases23. Lav70.2 needed 2K3 or above modes & all modes were tried. I get mixed results with Depends profiling programs; for instance LAV70.2-16 will not profile correctly with KEX22 when it truly works. Also my profile of HD Video Converter Factory on page 43 is not to be trusted as it stops where as running without profiling it runs and the GUI window appears. Comparing KEX22 with KEX23 with Apilog on LAV70.2 there seems no difference except that instead of the GUI for install window appearing the error message appears, see the LAV70.zip containing KEX22 & KEX23 text results.

Riched32 I believe is irreplaceable but Riched20 14.0.7155.5000 has only one missing import GetGyphIndicesW. Works with OfficeXP MSO.dll 10.0.6870.0: - no missing imports from this library.

NB It did seem that CloseHandle was correct for NtClose but it did not work, so I tried DeleteObject & works faultlessly so far. The Handle to the object would be closed first. If there was another handle to the same object, would the object stay in memory because the object handler does the checks? NVopenGl needs disabled again now. & working great; KEX23.

"NtClose is a generic routine that operates on any type of object.

Closing an open object handle causes that handle to become invalid. The system also decrements the handle count for the object and checks whether the object can be deleted. The system does not actually delete the object until all of the object's handles are closed and no referenced pointers remain."
 

LAV70.zip

Edited by Goodmaneuver
typo
Link to comment
Share on other sites

NtClose has not changed since ...18 (over two years), so the problem is not there.

Substituting DeleteObject for NtClose only acts as a stub and causes a resource leak. Also, it returns a BOOL so on failure returns zero which for NTSTATUS NTClose() means STATUS_SUCCESS.

BTW, if you are still using Kexstubs (any version), don't! It is not to be used for APIs that have already been added to KernelEx.

> "NtClose is a generic routine that operates on any type of object.
This is from the drivers documentation and only pertains to kernel objects (not GDI objects).

The Win32 documentation states: "Deprecated. Closes the specified handle. NtClose is superseded by CloseHandle."

It goes on to state that (like CloseHandle) it only closes the following (non-GDI) object types:

Remarks


The NtClose function closes handles to the following objects.

* Access token
* Communications device
* Console input
* Console screen buffer
* Event
* File
* File mapping
* Job
* Mailslot
* Mutex
* Named pipe
* Process
* Semaphore
* Socket
* Thread



Link to comment
Share on other sites

The only differences in the two log files are in OleAut32.dll. Make sure you are using version 2.40.4520 with KernelEx disabled.

-- G:\LAV70\L702_K22.TXT : G:\LAV70\L702_K23.TXT
Depth Thread Info Return
!> 1 #1 [OLEAUT32.DLL]77a278cf:GetEnvironmentStringsW(bfa5003e)
!> 1 #1 [OLEAUT32.DLL]77a278cf:GetEnvironmentStringsW = 4322d4
<! 1 #1 [OLEAUT32.DLL]77a27d53:IsProcessorFeaturePresent(bfa4c01c)
<! 1 #1 [OLEAUT32.DLL]77a27d53:IsProcessorFeaturePresent = 0


Edited by jumper
Link to comment
Share on other sites

> I get mixed results with Depends profiling programs

Depends.exe should be set (before launch) to the same mode as the KernelEx app being profiled.

> So it looks like KEX settings are determining differing outcomes.

Yes, that is the whole point of having settings!

Link to comment
Share on other sites

Oleaut32 when going back to 2.40.4520 and selecting disabled it does not alter Lav70 install error. It did allow setting disabled though. 2.40.4532 should be compatible I have been using 4532.0 for several years and just recently found 4532.3. (443 exports)

EliCZ has determined that :

Address: NTDLL.ZwClose == NTDLL.NtClose
Stub: NTDLL.ZwClose == NTDLL.NtClose == NTOSKRNL.ZwClose
So these all call NTOSKRNL.NtClose, which is the functional part, all other ??Close are
stubs.

from http://el1.cz/infos/Native.htm

CloseHandle returns 0 if fails as well Win32Doc-closehandle If looking at Msvcrt 7.0.3790.4341 which is product vs 6.1.8638.4341, it has only one Ntdll import - NtClose, so it is a good test for the NtClose function. Msvcrt if used as a system library has to work in safe mode. The DriversDocumentation document I quoted is still relevant for Ntdll.NtClose. MS documents to say NtClose is depreciated & there is no import library for this function does not make sense as Win10's User32 for example, imports NtClose from Ntdll.

I used to use Vuze 5.3 with 4.5.120 but now I have one build with JRE6 & KEX23; Vuze setting Win98SE and is only setting that all text is displaying correctly. On another build I have JRE7 working but Vuze only starts up with BASES, BASESN, DCFG1, or NT40 or above settings. The text is not displaying in the tabs nor in the seeding or download sections with NT40 + settings and does not look or perform as normal with the BASES, BASESN or DCFG1 setting. I can not use ApiMon with Win98SE setting as nothing shows before program terminates.

>Depends.exe should be set (before launch) to the same mode as the KernelEx app being profiled.
I thought the same thing but it did not make any difference the statements I said still remain correct that Depends does not profile correctly. I tried it again.

I will give a much more informative Log what is happening with KexBases23 results with all filter categories enabled with ApiMonitor available from http://www.rohitab.com/download/apimonitor.zip or .msi instead of .zip. APM files should be registered to open with ApiMonitor. Note some registry errors may be attributed to same CLSID numbers for Shell32 changing functionality with later Shell32 versions. I will try and fix some other registry errors before uploading results. : - Not much success but I unregistered some reg ShellEx settings from some unused libraries. I have saved as a XLS files so that highlighting of failures are shown in red. BTW LAV69 will do nicely.

I run Explorer with DCFG1 now. It can save some programs from having to have individual settings and still works the My Computer drive properties. Choosing any more advanced setting causes Explorer to terminate in an unusual way from a run-time error when the drive properties from within My Computer is selected.

LAV70.zip

Edited by Goodmaneuver
I could not emulate *\MSVC*.DLL >> WINXP KEX appearing as disabled error again
Link to comment
Share on other sites

Oleaut32 45.32 is Win2000 and 4532.3 is bwc24d. This first is actually older than 4520 for 9x; 4532.3 adds new functions to 4532. Search Google for "Oleaut32 2.40.4532" and you will find two MSFN.org threads from nine and five years ago that discuss which version is the best for 9x/ME. For systems without KernelEx, the answer is 2.40.4520 and it is the version used in all the latest service packs. That should be the version in Windows\System.

Optionally, later versions of Oleaut32.dll can go into Windows\KernelEx and be activated via [HKEY_LOCAL_MACHINE\Software\KernelEx\KnownDLLs], but only if they include the APIs: #442 RegisterTypeLibForUser, and #443 UnRegisterTypeLibForUser. (KernelEx already supports these functions, so this option is pointless at this time!)

> from http://el1.cz/infos/Native.htm

"EliCZ, Aug-15-1999" Obsolete information about NT4. NTAPI is the NT driver API. KernelEx does not support drivers or NTOSKRNL.

> CloseHandle returns 0 if fails as well

Correct. That is why it is called by NtClose instead of just being forwarded to.

> The DriversDocumentation document I quoted is still relevant & correct for Ntdll.NtClose.

Incorrect. Read the Requirements section: the document is for NTOSKRNL.NtClose, not NTDLL.NtClose!

> I have JRE7 working but Vuze only starts up with BASES, BASESN, or NT40 or above settings. The text is not displaying...

As described, this isn't a regression. When you figure out what changes need to be made to KernelEx to better support this JRE7/Vuze combination, let me know.

> Depends does not profile correctly.

Right. Depends works in undocumented, mysterious ways and often doesn't work as desired with KernelEx apps.

Link to comment
Share on other sites

4520.0 & 4532.0 were released at the same time, 4522 is an earlier release. I think that is what you meant.
NTAPI is Native Application Programing Interface. EliCZ said :
"Native API is for both modes, but runs in KM in NTOSKRNL. In UM is Native API connected to KM from NTDLL by following stub"
Wiki also confirms https://en.wikipedia.org/wiki/Native_API ."Nt or Zw are system calls declared in ntdll.dll and ntoskrnl.exe. When called from ntdll.dll in user mode, these groups are almost exactly the same; they trap into kernel mode and call the equivalent function in ntoskrnl.exe via the SSDT."
Nt prefixes in Ntdll are stubs as coders talk @ StackOverflow here.

Azureus ever since BitTyrant is IMO the best. The question is why does the text not display properly on the JRE6 build with WINME or WIN98FE modes? The other question is why does it not startup with WIN98SE on the JRE7 build?

Edited by Goodmaneuver
Link to comment
Share on other sites

NB Vuze works well with KEX20 with WIN98, WIN98SE or WINME settings. Introducing Core.ini20i & it stops starting with these settings & Java7. It is unusable with other settings. If IsProcessorFeaturePresent has not changed then there must be something wrong as the kernel is stopped from using this function when in 98, ME & NT6 modes. It is clear with KEX21- 23 Kernel.IsProcessorFeaturePresent.=none or =0 in NT6 case stops this function. Why is this implemented when all of these mentioned OS's have IsProcessorFeaturePresent in their kernel32.dll? Having the kernel.IsProcessorFeaturePresent=none introduces other ailments which require unnecessary mode settings.

>There is no change regarding IsProcessorFeaturePresent. It continues to be deactivated in Core.ini for non-NT modes. Try NT4 or W2K mode for apps/modules that need it. I'll see about creating an ITO(*) version that can be safely enabled for all modes.
It was not deactivated in Core.ini for non-NT modes so I have removed them in Core.ini20i. Working well now, best regards.
 

Link to comment
Share on other sites

Please debug what is going wrong with Vuze and JRE in W2k mode. Unless an app was written for NT4, if it calls IsProcessorFeaturePresent it should work on W2K. (There is no point to calling it on 9x/ME as they always return FALSE, and 95 doesn't even have it.)

>> It continues to be deactivated in Core.ini for non-NT modes.
I must have been looking at previous unreleased versions when I wrote that. I was adding and making lots of OS-related changes at the time.

> It was not deactivated in Core.ini for non-NT modes so I have removed them in Core.ini20i.
Good. The correct solution is to move "KERNEL32.IsProcessorFeaturePresent=none" to [WIN95.names] and remove all other references.

For everyone who reported problems with IsProcessorFeaturePresent back in July, thank you for reports and your patience. I will adjust the *.24 package and release it very soon.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...