NotHereToPlayGames

Yep. I hit the "report" link an hour or two ago. So the moderators are aware.

But don't let that discourage. This is LIKELY kinda going to go along the same lines of 360Chrome. I had high hopes it would reach a bigger audience then it has. But the reality is that XP, Vista, and 7 is a RAPIDLY declining user-base. I do have a Vista Extended Kernel installation, but I rarely log into that machine as it is HIGHLY unstable. Dual Boot. Vanilla Vista is ROCK STABLE. I have not (yet) dived into seeing if Vista Extended can be made "stable" (ie, "usable").

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.

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.

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".

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.

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.

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

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?

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.

@UCyborg - not sure I follow. Rebasing is new to me. This is what Process Hacker is showing -

Thus far, I'm kind of "mixed" on rebasing chrome.dll. I believe that we have to look at the entire picture and not base "everything" off of reducing RAM consumption. I've seen people jump up-and-down with ecstatic exuberation over saving a mere 3 MB of RAM - I don't understand that, at all, to be honest. Make no mistake, RAM consumption is cut drastically when we "rebase" chrome.dll. BUT it also comes at a COST. On my Intel Core2 Quad Q6700, my first launch coming out of hibernate or full-shutdown increased from 4 to 6 seconds (already too high but inline with Mypal, NM, St, and BNav!) to over 14 seconds (simply unacceptable!).

Back home from travels. Very limited testing thus far, but I cannot seem to be able to isolate any system gain or system degradation with comparing compressed loader to uncompressed loader. Only tested on x64 tonight, will revisit on another low-end x86 within the next day or two. Reminder that UPX (and PE) is an "in-place" decompression. UPX (and PE) is not like .NET assembly compression where the file is decompressed and that decompressed file is used "instead of" the compressed file. For UPX (and PE), the COMPRESSED file is being used DIRECTLY by the OS. It isn't decompressed on-the-fly and the decompressed exists side-by-side with the compressed and the OS uses the decompressed instead. Rather, the OS is using the COMPRESSED file DIRECTLY.

Agreed! I also use Actual Window Manager and have noticed this being a possible culprit for why the VERY FIRST launch of 360Chrome coming out of HIBERNATE or FULL SHUTDOWN takes a lot longer then later launches.

From what I am seeing with limited testing only on the cheap laptop that I travel with, I'm seeing it a less strain on CPU Surge to keep the loader COMPRESSED. I'll have to revisit when I can test on a couple of different PCs.

I have not looked into uncompressing it. Do we know if we can uncompress it? I personally DO use the loader because I do not want the registry entries "left behind" when I exit. I run too many different versions here and there and want the registry free of "left behind" entries when I switch between versions. I do run my own "loader" but it runs the "original" loader and then does certain items after the "original" loader is no longer running.

I have zero plans to do anything with the loader. I personally use it and see no issues with it, but I also have my own loader for experimentation (which I do not foresee going public with). If we screencap'd DNS entries or network traffic being conducted by the loader, that would be one thing. But to label it "suspicious" for NO DOCUMENTED REASON WHATSOEVER is not really worth "losing sleep over".

Agreed. I cannot investigate for a few days due to Holiday travels but my hopes is that a rebase of other .dll's will resolve first-run crashes on multi-monitor systems. I don't recall offhand, but I don't think the libglesv2.dll is "required", nor is the "swiftshader" folder - but again, some multi-monitor systems crash without these.

Yep, sure will. This truly is an AWESOME find!

This rebasing is VERY exciting news! Can't thank the "team" enough! I can't test until back home, but I'm starting to think that the rebase is why my multi-monitor setup at home crashes first launch and first launch only if I remove the Vulkan .dll's. Would also prove interesting to compare rebased 1030 with rebased 2022.

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

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.

I discredited this in the past because I saw no gain in x64, but there is a RAM-savings in x86 of roughly 115MB to 120MB if you disable "site isolation" via chrome://flags. edit - with site isolation disabled, my build 2022 at launch but only the empty tab sits at roughly 514MB. but my build 1030 sits only at 382MB. disregard, almost forgot - 1030 crashes on my multi-monitor x64 if i remove vulkan .dll's so i added them back in with 2022. even though i don't even have a vulkan graphics card.

Agreed. Interesting! Yes, very likely. Unsure how to track that down.