Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×

Recommended Posts

Because DLL forwarding does not work in WinME we forward the DLL in the registry by using KnownDlls. If the API set forwarded functions are in the DLL then just use KnownDLLs in registry to forward API set to the DLL. For example Jumper's API-MS-Win.reg would look like this for the first 3 registry additions. Kernel32.dll is in a mapped/known path so the full path name does not need to be shown to the registry.

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs]
"API-MS-Win-Core-Console-L1-1-0.dll"="Kernel32.dll"
"API-MS-Win-Core-DateTime-L1-1-0.dll"="Kernel32.dll"
"API-MS-Win-Core-Debug-L1-1-0.dll"="Kernel32.dll"

The .. means go to the parent folder (one above current one). The \ in the registry and folder paths means end of folder name and there is a child folder if named after the \. The \\ I do not think would make any difference to the \ but I would appreciate the difference explained. I think it would look 2 folders down but the \\ means that there would be nothing in the folder between the 2 \\ as it is unnamed and therefore would only look in child folder. I hope this makes sense.

Note I gave my known DLL list here https://msfn.org/board/topic/173233-kernelex-45-core-updates-45201617/?do=findComment&comment=1157548 which is out of date now but it will show more API sets and add Jumper's list to my list too.

I just downloaded my KnowDlls.txt and not all Msvcr90.dll redirects are the best choice for the API sets as some functions are not included in Msvcr90 so use DW to check for compatibility. I have chosen Msvcrt.dll now but it depends on what version of Msvcrt that you are using and you will need to choose an appropriate DLL for the redirect although if the missing function is not called then the redirect will still work for functions that are called. This is an advantage of using a forwarding DLL to a known DLL.

Edited by Goodmaneuver
Link to post
Share on other sites

Thanks for clarification and for the answers.

I also added these missing API names (Firefox52) to my Registry and took your values for them, Goodmaneuver. There remained four string values without value data only.

api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-timezone-l1-1-0.dll
"api-ms-win-crt-conio-l1-1-0.dll"=     ? tried MSVCRT.dll first
"api-ms-win-crt-convert-l1-1-0.dll"=   ? tried MSVCRT.dll first
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
"api-ms-win-crt-locale-l1-1-0.dll"=     ? tried MSVCRT.dll first
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
"api-ms-win-crt-process-l1-1-0.dll"=    ? tried MSVCRT.dll first
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll

------

My MSVCRT is 7.0.9981.0.

The others are already in API-MS-Win.reg of update 18.

This error message is gone "Error starting program - The ....Firefox\api-ms-win-crt-runtime-l1-1-0.dll file can't load the desired adress,
and is not relocatable.", but now it complains about api-ms-win-crt-convert-l1-1-0.dll on start. I have to find a better forward. I also will check with DW.


 

Win7 APIs.txt

Link to post
Share on other sites

WinME's Kernel32.dll can not be loaded in two different memory locations even if renamed, it is not relocatable, it would be locked in place with the hardware I would think. It sounds like api-ms-win-crt-runtime-l1-1-0.dll file being unable to access the desired address means you have not redirected it in registry because you would not get an api-ms-win-crt-runtime-l1-1-0.dll error, you would get the redirected DLL's name error. AFAIK  Jumper's registry settings can not be used as they are written. The registry should have just KERNEL32.DLL for example as the Value data. If Ktree says that KernelEx has catered for the function then KernelEx will do its thing, either stub it or redirect the function. Kernel32.dll and all KernelEx files like Kexbasen.dll should be set KEX disabled as Jumper said in the KernelEx-45-Core-Updates topic. I have not got api-ms-win-crt-runtime-l1-1-0.dll listed in my KnownDlls either so I have not come across its use or I have not got a suitable Dll for its replacement : - redirect. So I am not sure about Jumper's API-MS-Win.reg list unless the functions that the parent module calls are catered for by KernelEx. My current full KnownDlls reg entries are uploaded back into https://msfn.org/board/topic/173233-kernelex-45-core-updates-45201617/?do=findComment&comment=1157548 if anyone is interested and it will be zipped. I am using MSVCR80 vs 8.0.31113.25 renamed as MSVCRT as a system DLL in this build that uses the known Dll upload. Not all functions are catered for in some redirects so check with Dependency Walker by loading the module that calls the API-MS-WIN Dll module.
 

Edited by Goodmaneuver
missed out vital word - not
Link to post
Share on other sites

I have just checked out your API-MS-WIN modules and they need UCRTBASE.dll - they call for it anyway. UCRTBASE.dll uses API-MS-WIN modules so it is made WinME compatible with my KnownDlls.reg upload and UCRTBASE.dll set KernelEx BASE. You need to obtain module UCRTBASE.dll - (a Win10 module) and the API-MS-WIN modules are set to load UCRTBASE.dll in registry KnownDlls as explained. UCRTBASE loads with KEX24 I have tested it and am fairly sure of that. I will update my KnownDlls again once I have made changes to include the new API-MS-WIN modules.
 

Edited by Goodmaneuver
Link to post
Share on other sites

I got UCRTBASE.dll and now api-ms-win-...dll don't give me any more trouble. But now it tells me that VCRUNTIME140.DLL is associated with missing MSVCRT.DLL:terminate.
My MSVCRT.DLL is 7.00.9981.0
Here's my DW:
 

dw.jpg

Link to post
Share on other sites

I have discovered that if an executable needs to be run to load the implicit module/s then it can ignore the registry settings (many Win10 system executables with inbuilt icons exhibit this behavior). If this is the case then there are a few alternatives, 1 for example, rename UcrtBase.dll to the APIset name that the Exe is looking for or 2 edit the Exe to by changing the API-MS-WIN string to UcrtBase.dll if it allows it. KnownDlls redirect to UcrtBase.dll should solve the error with api-ms-win-crt-convert-l1-1-0.dll on start though. I am glad to have looked into the KnownDlls again as I had made some errors and have cleaned it up into the upload again. The file comparison is an exclusive difference, that is, if the function exists in all compared modules then it is not shown. I can do a comparison for other modules if anyone wants it. The new upload of KnownDlls should fix the VCRUNTIME140.dll errors. If looking into my KnownDlls there is ANSI version of Radmin32 in the Value data. KernelEx has worked functions that Radmin32 has but KEX works with the module name first for those, that is, KernelEx does not react to Radmin32's functions as Radmin32 it is not named Ntdll nor Advapi32 as examples. Most function calls now do not have "A" at the end which signifies ANSI so the Radmin32 functions that do have the A at the end will need the A removed in the Radmin32 function strings. Check with DW. It is a choice to make and check whether Radmin32 is acceptable as a Dll redirect or not.

Edited by Goodmaneuver
Link to post
Share on other sites

Checked it out, VCRUNTIME140.dll error is gone. But now UCRTBASE.DLL is associated with missing KERNEL32.DLL:IsProcessorFeaturePresent. Meanwhile DW shows that the import for it is resolved.

Compatibility mode for UCRTBASE.DLL is Base Enhancements (api fixes + extensions)

dw.jpg

Link to post
Share on other sites

Yes Core.ini should be edited and I have done so in an upload here https://msfn.org/board/topic/178283-how-you-really-browse-the-web-on-98me-in-2019/?do=findComment&comment=1178441 Replace Core.ini with my edited one and then reboot : - it is what Jumper wanted. The errors in the KnownDlls were that I left some with .dll on the end of their name and they were double ups except for the Unicows one so if you go into the registry location HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs delete any entries with .dll an the end of their name in the name section. If you merged the new upload then the Unicows one would be corrected but there will still be the old entry with .dll at the end of its name.
 

Edited by Goodmaneuver
Link to post
Share on other sites

Replaced it, now it just says it couldn't load XPCOM

Also, now FF47 crashes if I try to open it, although that one probably was because of LZDLL.reg. I'm gonna revert it for now.

EDIT: Ok, I've retraced my steps, and FF47 doesn't work with the new Core.ini - it doesn't start.

 

Edited by tyukok
Link to post
Share on other sites

Also, just to clarify: since I reverted back to how the system was before I installed any .reg files, I only installed the newest KnownDlls.reg. Do I still have to edit HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs?

Link to post
Share on other sites

Not really the .dll on the name is referring to modules that do not exist and should be cleaned. LZ32 is an old file and there are no extra functions other than that were present in WinME's version which I think is the best (check Win10's module). I remember trying LZ32.reg from KEX18 and it directed DNSAPI to LZ32 so "Dnsapi"="Kex\\..\\LZ32.dll" must work with KEX18. I commented about this in the Core-Updates topic. Those reg settings in KEX18 are to be avoided. You can go back to original Core.ini but I doubt very much that adding IsProcessorFeaturePresent back to the Kernel has got anything to do with stopping FF47. When you said you reverted do that mean you restored the registry and when was FF47 last working, you may need to go back in time to that period. The Core.ini has just got 2 lines of text removed that should not have been there. Check by comparing with your original. Once you try and launch a different version of FF the application data is shared unless a portable version is used and the directories are different or replaced with the new modules. The thing is though with different directories means the registry may not 100% as some settings may still be with the old directory. I would only experiment on a backup of your system and keep a copy of the application data/profile to go back to. Best thing to try is leave registry as it is without the LZ32.reg and remove the profile of FF or restore it if you have a copy. It is kept in Application Data\Mozilla if not portable version. I am not sure were portable profile is kept.

>>Replaced it, now it just says it couldn't load XPCOM

PDH amd WTSAPI32 must be a KernelEx knownDll in same folder as KernelEx and be in follower mode see https://msfn.org/board/topic/181424-firefox-24-for-me-and-98/?do=findComment&comment=1180695 otherwise XPCOM is missing error will occur. The last XPcom.dll that was compiled was for FF13 and it is not compatible with newer FF versions.

Edited by Goodmaneuver
Link to post
Share on other sites
3 minutes ago, Goodmaneuver said:

When you said you reverted do that mean you restored the registry and when was FF47 last working

No, I meant just deleting everything from the hard disk and restoring from a full copy I store on a separate disk. Just to be sure.

Due to how lightweight the whole install is, the whole thing takes only a couple of minutes.

Link to post
Share on other sites

Manually edited CORE.ini to be like in https://msfn.org/board/topic/178283-how-you-really-browse-the-web-on-98me-in-2019/?do=findComment&comment=11784 and now FF47 runs like it did before. Odd.

1 hour ago, Goodmaneuver said:

PDH amd WTSAPI32 must be a KernelEx knownDll in same folder as KernelEx and be in follower mode

How does one set .dlls into follower mode, again?

 

Link to post
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...