Firefox 24 - 52 for ME and 98

[Goodmaneuver]

Just have them no mode selected in registry. This means the right click module properties will have the top 'Use default compatibility options (KernelEx is enabled)' radio button selected. I was thinking then perhaps not have UCRTBASE selected KernelEx BASE. In other words do not change any KernelEx settings. Keep a Known good profile of FF. It might have been FF profile changes. The other thing is depending on how the LZ32.reg affected the registry. I think Lz32.reg redirected Dnsapi to lz32 along with other other redirects. Registry could have changed or if processor hit hard against a solid fault then hardware could have changed momentarily and it is OK now.

Edited December 19, 2020 by Goodmaneuver

[tyukok]

Tried out both - no dice, still could not load XPCOM

Here's my knowndlls

knowndlls.reg

[Goodmaneuver]

11 hours ago, tyukok said:

Tried out both - no dice, still could not load XPCOM

Do you mean that you tried FF47 and FF52? If so did you try FF47 first, You used to be able to use different FF executables to start FF and then you edit the application.ini and platform.ini to suit your extensions. Perhaps if you set FF47 working again then you might be able to swap out FF52 executable with FF47's for a try. Check with DW if compatible first. Your KnownDlls has still got the error ones I made in it. Do a search of -0.dll in the KnownDlls section of the registry and delete the entries then do a search of -1.dll and delete those. It might also be a good idea to wait till Schwups gets back as I have not been experimenting on FF. The extra KnownDlls would have been placed there by the OS they are not essential because the module name is not changed. The 16bit Known16dlls will return though if deleted. I removed any reference entries that were 32 bit modules in the Known16dlls section.

Schwups Jumpers explanation of the kex\\..\\ is precise. There is no quote-mistakes ("") inside the Win7 APIs file but if file redirection did not occur then there is a problem. You removed KEX\\..\\ and redirect did occur. That is what happened isn't it?

>>"The DependencyWalker doesn't find these files. In other words, it can't handle KernelEx"

It is because KernelEx folder is not mapped to an environmental variable, that is, not in a mapped/known path. Thus means for PDH and WTSAPI32 modules that are in the KernelEx directory are only known by KernelEx. The FF or any other program or module cannot directly link to the files in the unmapped directory. I do not think that these two files are used at all by the startup of FF but if they are found by FF then we get the XPcom.dll is missing error.
 

Edited December 20, 2020 by Goodmaneuver

[tyukok]

3 hours ago, Goodmaneuver said:

Do you mean that you tried FF47 and FF52?

No, I mean I tried fiddling with PDH and WTSAPI32, as well as setting UCRTBASE to follower mode.

FF47 now works fine. Whatever was the reason for it not working before, a full restore followed by me retracing my steps fixed it. Gonna try swapping the exe.

EDIT: tries swapping exes - no luck, still couldn't load XPCOM.

But here's something else I've noticed: when I reverted back to how the system was before installing any .regs, I used the new CORE.ini, then installed API-MS-Win.reg, and then an older version of knowndlls.reg - I got VCRUNTIME140.dll error as a result, just like before. But when I installed the new knowndlls.reg after that, I got XPCOM error.

Edited December 20, 2020 by tyukok

[Goodmaneuver]

Yes API-MS-Win.reg should not be used as it directs the APIset modules to Msvcrt not Ucrtbase. The older version of knowndlls.reg should be disbanded too as I had not added and changed all APIsets that call UcrtBase to use UcrtBase. XPCOM is not an error as such really, it is asking for that file which was provided up until FF13 but then was dropped and it might be a default error message. The XPCOM message is a step in the right direction over a module we have installed error.

What you did is find out how marginal the loading of FF is. Did you try keeping a FF profile after FF47 works with a smooth exit then reinstalling that profile after the XPcom mis-load or re-instate the registry by doing a scanregw /restore. I would do a second reboot first after the registry reinstatement to be sure. Patching the disc with backed up data might be easier than erasing the whole disc each time, it may not work though will narrow down easier the issues. Can you browse pages properly in different sites good without browser locking up?

Referring to your last paragraph: You have started up FF52 because UcrtBase is used. This will affect your system and the gives XPcom message when starting FF47 afterwards is that right? See Schwups has to start DW several times to get the missing modules to indicate. This is unusual and indicates that his resources are stretched to the limit in some area which I do not know. It will be set in registry as a buffer size / cache and operate from there but knowing what / where the setting is is the challenge. What is the cache that DW uses when opening many different modules, the text is first to go but is probably a different cache to that of having to start DW several times. The cache size might be the same but it is filled more before Schwups opens DW or something like this. This is different for me. There has a lot of effort placed in getting FF later versions working but this browser is a cross platform one with a lot of overheads as a consequence. I would like to see Maxthon browsers looked at as they can work the websites properly. Maxthon Nitro is a slim browser I will comment elsewhere if after testing in Win7 and is OK.

Edited December 22, 2020 by Goodmaneuver

[Goodmaneuver]

The 16 bit cache / buffer sizes could be written into the drivers so the 82.16 graphics driver could be significant but I can not find it. I tried opening XUL FF47 several times with DW and the extra files that Schwups sees are not showing in my DW but if he is profiling FF47 then this is different and my previous post comments about it will be not relevant.
 

[schwups]

 

6 hours ago, Goodmaneuver said:

The 16 bit cache / buffer sizes could be written into the drivers so the 82.16 graphics driver could be significant but I can not find it. I tried opening XUL FF47 several times with DW and the extra files that Schwups sees are not showing in my DW but if he is profiling FF47 then this is different and my previous post comments about it will be not relevant.
 

 

https://web.archive.org/web/20060721180029/http://www.bfgtech.com:80/images/NVIDIADisplayWin9x(82_16)int.exe
http://toogam.com/software/archive/drivers/videodrv/mswinvid/nvidia/unoffici/   (82.16 19M file)
I'don't believe that 82.16 is mattering here.

Quote-mistakes ("") inside the Win7 APIs file: The quotes after ntdll.dll are missing, therefore these reg entries will not exist.
"API-MS-Win-Core-RtlSupport-L1-1-0"="Ntdll.dll
"API-MS-Win-Core-XState-L1-1-0"="Ntdll.dll

LZDLL(_ME).reg: It is highly unlikely, that this reg file update make sense here! FF48 runs without these reg entries.

Core.ini - differences:

- [Base.names.98] and [Base.names.Me] Kernel32.IsProcessorFeaturePresent=none (taken out)

- [WIN95.names] KERNEL32.IsProcessorFeaturePresent=none (added)

- [NT40.names] KERNEL32.IsProcessorFeaturePresent=kexbases.0 (taken out)

- (Kexstubs is missing)

Goodmaneuver, I haven't tested with your knowndlls reg file so far - it is still pending. I have my KernelEX knowndlls reduced much more FF49-52 specific. I'm also reached the point that I couldn't load XPCOM.

 

[schwups]

After all I can enable Hardware Acceleration (GPU Accelerated Windows 1/1 Direct3D 9 (OMTC)) on KM76.3.
But for the moment, I don't see any advantage over "Basic" for this browser on ME.
- layers.acceleration.force-enabled    true
- layers.prefer-d3d9    true

I get a black browser window, if I do this on KM74Goanna.

Somewhat funny tests with PaleMoon27/MyPal27  (unknown Error on start): Basically I can start and run this program, but with K-meleon.exe of the same platform version.
I get a very simple KMeleon GUI (tab bar - url bar). So the problem seem to be correlated to the PM.exe and KernelEx.
The DependencyWalker shows only a few contemplable red unresolved c functions.
These API's are supported by KernelEX 24 - kexbases: DecodePointer, EncodePointer, GetModuleHandleExW, SetDllDirectoryW, SetFilePointerEx. I suspect this is where the problem lies. My derivation can also be wrong.

Tests with FF52 are still pending.

 and a very small update for Kexstubs:

[KERNEL32.DLL]
RoGetActivationFactory=
WindowsCreateStringReference=

[tyukok]

On 1/4/2021 at 4:06 PM, schwups said:

Somewhat funny tests with PaleMoon27/MyPal27  (unknown Error on start): Basically I can start and run this program, but with K-meleon.exe of the same platform version.
I get a very simple KMeleon GUI (tab bar - url bar). So the problem seem to be correlated to the PM.exe and KernelEx.
The DependencyWalker shows only a few contemplable red unresolved c functions.
These API's are supported by KernelEX 24 - kexbases: DecodePointer, EncodePointer, GetModuleHandleExW, SetDllDirectoryW, SetFilePointerEx. I suspect this is where the problem lies. My derivation can also be wrong.

Interesting. I also did some tests with older versions of Pale Moon and MyPal. The version 24.7.2 of Pale Moon started up and ran immediately after I set compatibility mode for palemoon.exe and xul.dll to XP SP2. No graphical glitches or anything. Worked fine until I tried to go to any website that uses JavaScript in any way, shape or form. Then it froze just like K-Meleon on 98.

Then I tried to run MyPal 28.0.1. Set up the same compatibility mode for the same files. When I tried to run it nothing visibly happened, but, interestingly, it DID appear in the Task Manager. It seems like an interesting direction to look into.

Here's my DepWalker for it, in case anyone's interested:

Edited January 5, 2021 by tyukok

[schwups]

Yes, PM 24.7.2 runs here, too. The profile should be fresh and not mixed with other versions. I noticed that the plugin container continues to run in the background after PM close.
 

19 hours ago, tyukok said:

Then I tried to run MyPal 28.0.1. Set up the same compatibility mode for the same files. When I tried to run it nothing visibly happened, but, interestingly, it DID appear in the Task Manager. It seems like an interesting direction to look into.

You are one step further. I tried 28.0.1, but I get "couldn't load XPCOM" on start.

[tyukok]

23 hours ago, schwups said:

You are one step further. I tried 28.0.1, but I get "couldn't load XPCOM" on start.

I have Goodmaneuver's KnownDLLs, as well as edited core.ini, so that's what might be causing it. I put ucrtbase.dll directly into System folder and set compatibility mode as Base enhancements. Also I didn't use the installer for Mypal, only unpacked the files.

[schwups]

 

On 1/6/2021 at 8:38 PM, tyukok said:

I have Goodmaneuver's KnownDLLs, as well as edited core.ini, so that's what might be causing it. I put ucrtbase.dll directly into System folder and set compatibility mode as Base enhancements. Also I didn't use the installer for Mypal, only unpacked the files.

Sorry, I still haven't tested it.

---

For completeness: PaleMoon versions 25.1 - 25.4.1 are not affected by the running plugin container after close.
25.4.1 is the newest I can currently run. These versions based on Gecko 24esr and yes they don't have the icon glitches, which come with Gecko28 (FF28) and
slightly shifted or coloured edges, which occured around Gecko42. Extensions: PlainOldFavorites is compatible and QuickJava 2.0.5 has limited compatibility according to my first impression.

Currently discussed squares instead of icons in Firefox: https://msfn.org/board/topic/176837-disable-web-fonts-in-google-chromemozilla-firefox and https://msfn.org/board/topic/182240-missing-buttoncontrol/
One solution: "gfx.downloadable_fonts.enabled" = false =>  possible frayed fonts and icons

To test

gfx.use_text_smoothing_setting = true ("hardware acceleration" may be required - "layers.acceleration.force-enabled" = true)
layout.css.osx-font-smoothing.enabled = true

Edited January 7, 2021 by schwups

[schwups]

Now, I'd merged your Knowndlls reg file, Goodmaneuver, so I have two registry versions.
Then I can start ME via scanreg \restore with your "knowndlls"- reg version for testing at any time, too.
First tests brought nothing new last night.
Also early MyPal 28.0.1 didn't run in the background and I got "couldn't load XPCOM" again.
DW missing the old win95 file RLOCAL32.DLL due to RADMIN32.DLL I don't have.
I suppose that has nothing to do with the actual problem "couldn't load XPCOM".
I don't have the following files either: CLFS.SYS, TQUERY.DLL, LOGONSRV.DLL, MaxAPI.dll, NLS.DLL, SDBAPI.DLL, MOZCRT.DLL
Of course, these files are irrelevant here to run FF49+.

Edited January 9, 2021 by schwups

[tyukok]

29 minutes ago, schwups said:

early MyPal 28.0.1 didn't run in the background and I got "couldn't load XPCOM" again

An important addition I forgot to mention: I was testing it on 98SE.

I installed ME to see if anything might be different, installed KernelEx in exactly the same way as I did on 98SE, used the same DLLs, same compatibility settings, same registry values - and I got XPCOM error here too.

[Goodmaneuver]

MOZCRT is a renamed MOZCRT19.dll last used in FF8, it has some rather updated functions which is best shown with an upload of comparison differences. LOGONSRV and RLOCAL32 are found in U98SESP3.64; - just extract DSCLIENT.exe. Functions in NETUI1.dll will have to match RADMIN32 functions if used when Radmin32 strings have been altered. TQUERY is from Office XP I think, vs is 10.109.3705.2 not all functions are there to replace QUERY.dll but a lot are.  MaxAPI.dll is to correct a "MAX" module name that was missing in DW for a module. MaxAPI.dll is a PaperPort11 module - which is WinME compatible. NLS.dll from LH5381 will do. CLFS.sys from LH5048 will do. SDBAPI is from MESP1 which is SP2 AFAIK; - just extract INSTMSIA.exe.

Me not knowing much about KexStubs wasted a lot of our time. I would like to know the Core.ini - (KexStubs is missing) details. Thanks for the driver link. Some LH prereleases can be obtained from winwoldpc.com 

MSVCRT compare.zip

Edited January 10, 2021 by Goodmaneuver
CLFS not SLFS