ArcticFoxie/NotHereToPlayGames -- 360Chrome v13.5.2022 rebuild 3

[gerwin]

12 hours ago, msfntor said:

@gerwin, but why you run alg.exe, ctfmon.exe...I don't run them.

ctfmon.exe is a useless and stubborn MS Office 2003 related service. I remove it sometimes, sometimes I forget.

Then alg.exe, I am not sure. It is a manually started MS service, the question is what starts it? Windows XP Firewall maybe? https://www.auditmypc.com/alg.asp

[AstroSkipper]

1 hour ago, UCyborg said:

Seems chrome.dll needs to be rebased. It uses the default preferred base address used by MS build tools (which is constant) and is unable to be loaded at its preferred base address on my XP and the DLL itself is huge, so it seems logical if the OS has to duplicate huge chunk of it in every chrome.exe process to be able to fix-up addresses inside, that would be costly in terms of memory.

I did rebasing when I patched old games (at least those I've spent most time working on) that used DLLs, which were small and these games don't spawn multiple processes. Back then I found the tool that chose the address based on the name of the DLL with optional INI file to specify base address and separation (how much apart they should be in the address space). I think the idea is to line up DLLs of your application at higher addresses, preventing conflicts with each other or another system softwares' / utilities' DLLs so OS doesn't have to rebase them at load time. Having them loaded in upper portion of the address space should leave large contiguous space for memory allocations.

Some interesting reading here and here. There's the hint why you don't see the issue on Vista+.

Anyway, here's the tool (libase.zip), it's in the Release subfolder, have both chrome.dll (from Chrome\Application\13.5.2022.0 folder) and libase.exe in the same folder, open CMD, cd to that folder and run:

libase chrome.dll

Copy chrome.dll back, launch the browser and check the memory consumption.

No idea where the tool was originally published and who wrote it, I think it came only in source code form and I wrapped it inside Microsoft Visual C++ 6.0 (another dinosaur) workspace file and compiled it. Microsoft has their own tool in their compiler suite that can also rebase executables and DLLs (reference).

So it's an issue that is easily fixable, but not many people seem to pay attention to such details. Rebasing other browser's DLLs should also save a little bit of memory.

Well, I do assume things at times.

Hello @UCyborg! You are great!  I have chrome.dll rebased, and now 360Chrome 13.5.2022 consumes much less RAM than before, such as it is the case on many other systems. Here is a screenshot:



The total of RAM usage is now 4.4 + 28.05 + 22.61 + 13.24 + 31.52 + 20.25 = 120.07 MB

Thank you very much!

Greetings from Germany and Merry Christmas!
AstroSkipper

Edited December 22, 2022 by AstroSkipper
Update of content

[gerwin]

38 minutes ago, UCyborg said:

I can upload my chrome.dll for others to try. It should make the difference in case you currently see chrome.dll in orange in Process Hacker when you open 360chrome.exe and go to Modules tab (should no longer be orange with the old new DLL). At least the chance is very low that it still fails to load at its new address, if it does fail, it'll be orange again (bad!).

Thanks a lot!, I can also confirm this rebased dll cuts chrome360 memory allocation to about a quarter compared to the original dll.

[mixit]

@UCyborg An excellent approach!, works as intended on my XP x64. It's pretty funny that even though I've already personally modded this DLL, it didn't even occur to me to consider such "invasive" methods at this point - typically when people have these kinds of issues, they don't want to start modding as the first thing (breaking file signatures is "bad"! what will anti-virus say?! ), so you kind of condition yourself to try and find configuration-based methods first and foremost. But since we're modding anyway, this is highly appropriate!

For those who want to use this method for other applications, it seems that libase.exe doesn't like file signatures (my 1030 chrome.dll still had it while 2022 doesn't), which you can remove for instance with delcert.exe, available from here.

Edited December 22, 2022 by mixit

[XPerceniol]

1 hour ago, UCyborg said:

I can upload my chrome.dll for others to try. It should make the difference in case you currently see chrome.dll in orange in Process Hacker when you open 360chrome.exe and go to Modules tab (should no longer be orange with the old new DLL). At least the chance is very low that it still fails to load at its new address, if it does fail, it'll be orange again (bad!).

Holy smoke ... !!

@UCyborg gosh .... like night and day difference - YOU just made this browser quite nice and many thanks and happy holidays to you.

[mina7601]

54 minutes ago, gerwin said:

Then alg.exe, I am not sure. It is a manually started MS service, the question is what starts it?

The service Application Layer Gateway Service starts alg.exe.

[XPerceniol]

15 minutes ago, mina7601 said:

The service Application Layer Gateway Service starts alg.exe.

I have the service set so manual. 

[AstroSkipper]

39 minutes ago, mixit said:

@UCyborg An excellent approach!, works as intended on my XP x64. It's pretty funny that even though I've already personally modded this DLL, it didn't even occur to me to consider such "invasive" methods at this point - typically when people have these kinds of issues, they don't want to start modding as the first thing (breaking file signatures is "bad"! what will anti-virus say?! ), so you kind of condition yourself to try and find configuration-based methods first and foremost. But since we're modding anyway, this is highly appropriate!

For those who want to use this method for other applications, it seems that libase.exe doesn't like file signatures (my 1030 chrome.dll still had it while 2022 doesn't), which you can remove for instance with delcert.exe, available from here.

Hello @mixit! You are absolutely right! I also tried to rebase the chrome.dll of 360Chrome 13.5.1030 rebuild 6 and failed. Only after removing the file signature with your recommended tool delcert, I was able to rebase this chrome.dll, too. Thanks for your tip!

Kind regards, AstroSkipper

[IXOYE]

Hi

2 hours ago, UCyborg said:

I can upload my chrome.dll for others to try. It should make the difference in case you currently see chrome.dll in orange in Process Hacker when you open 360chrome.exe and go to Modules tab (should no longer be orange with the old new DLL). At least the chance is very low that it still fails to load at its new address, if it does fail, it'll be orange again (bad!).

UCyborg, Thanks for chrome.dll, it lowered the memory by 3 Mb, and it also solved the problem of the two orange addresses below with their disappearance.
with the new chrome.dll.

[mixit]

On 12/22/2022 at 11:13 PM, UCyborg said:

No idea where the tool was originally published and who wrote it, I think it came only in source code form and I wrapped it inside Microsoft Visual C++ 6.0 (another dinosaur) workspace file and compiled it.

Seems to originate from Dr Dobb's (source code links are dead there, but it's available here).

@AstroSkipper might appreciate how period correct this little program is.

Edited December 24, 2022 by mixit
grammar

[msfntor]

I see in Process Hacker (in 360Chrome 13.5.2022r3 regular latest version browser):

In my two 360Chrome.exe and too in 360Loader.exe (is packed process here) - I've Normaliz.dll in orange in Process Hacker...

then in one another 360Chrome.exe I see libegl.dll (360 KB), libglesv2.dll (2.66 MB), and mfplat.dll (124 KB)- in orange ...

- and this same in 360Chrome 13.0.2170 r1ung.

 

In 360Chrome 13.5.1030 r 5 - from five 360Chrome.exe processes only (so 360Loader.exe NOT present), have two only with Normaliz.dll in orange. That's all.

Edited December 24, 2022 by msfntor
For 360Loader.exe added: (is packed process here)

[AstroSkipper]

12 hours ago, mixit said:

@AstroSkipper might appreciate how period correct this little program is.

And again, you are absolutely right! In some special cases, it's better to use old programs on old systems what you may call "period correct". They were developed for these anchient OSs, and one can avoid problems that much more modern programs can cause. I have often experienced this on my old computer. 

[NotHereToPlayGames]

Awesome!

I'm on the road traveling for Holiday.

I'll do some experimenting with all this new info.

Many thanks for this thread finally returning to a high degree of USEFULLNESS.

[XPerceniol]

8 minutes ago, NotHereToPlayGames said:

Awesome!

I'm on the road traveling for Holiday.

I'll do some experimenting with all this new info.

Many thanks for this thread finally returning to a high degree of USEFULLNESS.

Have a safe drive and wishing you a happy holidays to you and yours.

[NotHereToPlayGames]

16 hours ago, UCyborg said:

I can upload my chrome.dll for others to try.

For my own compare/contrast learning curve, what was the original .dll that you rebased?