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

[UCyborg]

Do as you want. I've rebased chrome.dll with REBASE.EXE to be closer to wow64.dll on 64-bit XP, 17 MB gap before it was reduced to somewhere below 1 MB, so went from 0x62A00000 to 0x63A00000. Good enough for me and those occasional boots to XP, no side effects. No comment on 14s delay, first time I hear of it, maybe rebase to the address the OS chooses itself when it has to relocate the DLL from default 0x10000000?

Edited December 26, 2022 by UCyborg

[NotHereToPlayGames]

@UCyborg - not sure I follow.  Rebasing is new to me.

This is what Process Hacker is showing -

[UCyborg]

If you uncheck Hide free regions, it shows free spots and I noticed on my system there was cca. 17 MB free region between rebased chrome.dll at 0x62A00000 and wow64.dll. Though I didn't keep the browser open long enough to notice rsaenh.dll loading a bit later, which has preferred base address set to 0x68000000 (you can check that with Tools->Inspect executable file...BTW, it's possible that thing will erroneously show 64-bit hex number on XP x64, despite looking at 32-bit DLL, if I'm not mistaken, if you cut it in half and look at the first part, that should be correct), which then had to be relocated since part of its space was occupied by huge chrome.dll, which wouldn't have to be otherwise.

Your screenshot shows chrome.dll made it to default 0x10000000, so the issue with big consumption doesn't occur. If you go really nitpicking, I think you'd ideally want DLLs crammed somewhere together to reduce address space fragmentation, in the 90s, you could have those DLLs all over the place at higher addresses and it wouldn't be a problem since address space (4GB - 2 GB usable) was huge compared against available RAM capacities, but today, you can easily consume it all, but again, in this case we're dealing with Chromium that splits itself in multiple-processes...does single Chromium process ever start to consume as much in practice that it would become the problem?

I know it looks weird when you look at it at first, but basically every 32-bit process has 4 GB virtual address space to play with where its data in RAM are mapped, executables not marked with Large Address Flag are capped at 2 GB, though practically utilizable numbers are smaller. If I remember correctly, these things are explained in Windows Internals, one cool and long book about Windows technicalities.

Oh, the REBASE.EXE I mentioned, it's the tool that was bundled with older Microsoft Visual C++ IDE (Integrated Development Environment), maybe also older Microsoft Visual Studios (individual suites for each language (C++, Visual Basic...) were later combined into one Visual Studio, well, the tools are still separate, there's just one big program from where you open project files and edit code).

Edited December 26, 2022 by UCyborg

[mixit]

1 hour ago, UCyborg said:

Oh, the REBASE.EXE I mentioned, it's the tool that was bundled with older Microsoft Visual C++ IDE (Integrated Development Environment), maybe also older Microsoft Visual Studios (individual suites for each language (C++, Visual Basic...) were later combined into one Visual Studio, well, the tools are still separate, there's just one big program from where you open project files and edit code).

It's also included in the Windows 7 SDK (GRMSDK_EN_DVD.iso), still freely available straight from MS. Those who don't want to install the whole thing can use something like lessmsi to extract ReBase.exe from \Setup\WinSDKTools\WinSDKTools_x86.msi and its adjacent cab1.cab. And those who don't want to download the entire 500+ MB SDK from MS can use Archive.org's browsable ISO content to only get these two files.

[NotHereToPlayGames]

Is it safe to assume that I can rebase chrome.dll for x86 then just let my x64 files fall where they want in RAM?

It seems my x64 is already doing that since my chrome.dll made it to default 0x10000000 - I have not done any of these checks on x86 yet.

When I carried the rebased .dll from my primary computer (x64) to my secondary and had to wait 14 seconds for 360Chrome to launch, I basically stopped right there so far.

[NotHereToPlayGames]

I should be pulling this from my x86, but for reference and learning-curve - is this what I should be looking for?  Basically, rebase chrome.dll to avoid the 57,664 kB "free" region caused by using default 0x10000000?

[NotHereToPlayGames]

13 hours ago, UCyborg said:

Do as you want. I've rebased chrome.dll with REBASE.EXE to be closer to wow64.dll on 64-bit XP

Did you go this route because wow64.dll always sits in the same region?

[msfntor]

Found these two tools, hope this helps:

DLL Relocation Finder (by SecurityXploded): https://securityxploded.com/dll-relocation-finder.php

About: 

DLL Relocation Finder is the command-line Tool to detect and list Relocated DLLs in the Process.

Every DLL specifies a base address where it should be mapped during load time. However if that address is occupied by some other DLL then this DLL has to be relocated to new base address. This is called DLL Relocation or DLL Rebasing. This relocation process also happens for ASLR enabled modules. 

In such cases, DLL Relocation Finder helps you to find these relocated DLLs and their new addresses. It also provides option to list only relocated or non-relocated or both type of DLLs.

 

Massive Rebase: DLL Sharing and ASLR Investigation

This tool was written to demonstrate the positive effect of dll sharing by the operating system and the negative effect of dynamic dll rebasing. It is also useful when investigating software, such as application virtualization software and other filter drivers, that might interfere with this important memory sharing.

As explained my the book “Windows System Performance Through Caching”, the Microsoft operating system cache tries to save memory by allowing multiple processes to share executable file images in RAM. DLL files are commonly used by numerous applications and by having a single instance of them in RAM, considerable memory is saved. Sometimes, however, a dll cannot be loaded into the process memory location that the developer intended, causing the OS to "rebase" the dll on the fly. The OS accomplishes this by using "copy on write" memory and when the rebase fixups are applied, the process gets a new copy of those memory pages.

About Dll Base Address and Rebasing: read more and download (on tmurgent.com): https://www.tmurgent.com/appv/index.php/en/resources/tools/137-massive-rebase

[msfntor]

"So to sum up, I think that rebasing isn't worth the trouble except for special cases like the system DLLs."

- here, question on stackoverflow.com: "Is rebasing DLLs (or providing an appropriate default load address) worth the trouble?": https://stackoverflow.com/questions/3969190/is-rebasing-dlls-or-providing-an-appropriate-default-load-address-worth-the-tr

[NotHereToPlayGames]

1 hour ago, msfntor said:

"So to sum up, I think that rebasing isn't worth the trouble except for special cases like the system DLLs."

That's basically what I have been seeing so far.

All I can speak for is "my" computers and the trade-off effect, the "law of unintended consequences".

Lowering RAM consumption from 780 - 855 MB range all the way down to 222 MB is truly awesome, make no mistake.

BUT on "my" computer, it comes at the cost of it taking three times as long to launch.

I'm too impatient to wait "that long" for my web browser to launch - especially considering I "have" that 780 - 855 MB "to spare".

The best trade-off I'm finding is to UXP chrome.dll.

While this was introduced into the discussion with the innuendo of REMOVING it on the loader, our best balance seems to be to NOT "rebase" chrome.dll and KEEP the loader UXP-compressed but then ALSO UXP-compress the un-rebased chrome.dll.

 

edit - correction, UXP'ing chrome.dll does reduce FIRST LAUNCH after hibernate/full-shutdown, but it increases consecutive launches more then it reduces that first launch.

Edited December 27, 2022 by NotHereToPlayGames

[NotHereToPlayGames]

Actually, to word that a little differently -

I'm finding that rebasing chrome.dll has to be performed with the underlying knowledge of where all my system and background apps have all of their .dll's placed in RAM.

But as a "public release", we could never rebase chrome.dll to an address that is going to work for "everybody".

At least that's my interpretation thus far.

[NotHereToPlayGames]

19 hours ago, UCyborg said:

Do as you want. I've rebased chrome.dll with REBASE.EXE to be closer to wow64.dll on 64-bit XP, 17 MB gap before it was reduced to somewhere below 1 MB, so went from 0x62A00000 to 0x63A00000. Good enough for me and those occasional boots to XP, no side effects. No comment on 14s delay, first time I hear of it, maybe rebase to the address the OS chooses itself when it has to relocate the DLL from default 0x10000000?

I'm getting positive results on x64 - piece of cake!

But x86 is an entirely different story, sadly.  My best (so far), is to place chrome.dll contiguously 56 kB higher than where chrome_elf.dll resides.

For me, this rebases chrome.dll at 0x1d10000.  (edit, the only switch I used was -b)

But I have to wait between 14 and 22 seconds for 360Chrome to launch - x86 ONLY.

 

I guess it becomes a question directly to the x86 end-user.

I personally prefer my browser launching in under 5 seconds but consuming ~780 MB of RAM as opposed to consuming ~220 MB of RAM but taking over 14 seconds.

I can walk to the opposite end of the house in under 14 seconds and use the higher-end computer.

LAUNCH TIME is a higher priority for "my usage".

 

Edited December 27, 2022 by NotHereToPlayGames

[D.Draker]

4 hours ago, NotHereToPlayGames said:

5 seconds

Something's very wrong , 360 explorer starts in 0.5 secs on my old crap from 2009.

@UCyborg and everyone else who are left, sorry , I was busy butchering the latest Opera.

And I made myself a browser based on Chrome 110. Wouldn't it be easier to just use CFF explorer to rebuild, lol ?

[NotHereToPlayGames]

Mine loads in FIVE seconds for one and ONLY one lauch AFTER the computer comes out of hibernate or a full shut-down.

OTHERWISE, every other launch IS less than HALF a second.

Edited December 27, 2022 by NotHereToPlayGames
typo

[NotHereToPlayGames]

Congrats on butchering rebuilding Opera.

Us on XP can't use it.  I do have a Win7 lying around, but I do not (and will not) install any "extended" kernels.

But otherwise "congrats".  You have something that fills your needs.  The rest of us still have something in 360Chrome that fills our needs.