NotHereToPlayGames

That's the direction I am leaning also. One version that should work well for x86 users and for x64 users. I'm pretty sure that ASLR overrides anyway for Vista+.

Same here. But a thousand times more important is that I can access all of my bank account and bill pay web sites with it on XP. NOTHING else exists (yet?) for me to continue to do that on XP.

@mixit - how where you able to isolate the QR Code and Translate to English context menu entries? Was there a specific software debugger you used? I've been able to edit your build 2022 patches to work with build 1030 but I'd like to verify them with the method that you used as a compare/contrast.

I've also been comparing/contrasting libase with ReBase. ReBase has a nice "coffbase" feature that I'm still experimenting with.

I agree. I've actually been using 13.5 build 1030 for the last three days. Still experimenting with rebasing it for my x86 machines. I am undecided as to whether I will upload download links for my newest 13.5 build 1030 here at MSFN.

Yeah, it's that FIRST LAUNCH afer coming out of system hibernate or a full shutdown that concerns me. Always has. Consecutive launches were always fine. Browsers taking 4 to 5 seconds to launch for the FIRST LAUNCH is not that uncommon. In 2020 or so, I dropped down to Mypal 27.9.4 because it had a first-launch of 2.7 seconds compared to 4+ for all of Roytam's builds. The fastest Roytam NM27 was dated 10-27-17 and was equivalent to Official Pale Moon 27.6.2. These both had a first-launch of 2.8 to 2.9 seconds.

I recall seeing that about a month ago. At that time, the only change was from manifest 2 to manifest 3. None of the underlying .js/.css was changed. So there were no "improvements", just the developer jumping on the manifest 3 bandwagon.

You have demonstrated over and over and over again on this forum that you can not take "constructive criticism". You have the very unique ability to pick a fight with inanimate objects, so you can only imagine how you come across to those of us that are "animated". You have the very unique ability to walk into an EMPTY ROOM and come out with blood on your knuckles. Most of us here have just grown to "accept" it, you are who you are. But so are we, we are who we are. I hate the phrase, but I'll use it anyway - "it is what it is".

Moderators have already removed the post. Unfortunately, you replied to it and copied it in totality, so moderators should probably remove that also. Or at least remove the link that the spammer dropped on our forum.

"Guy" in the US is a gender-neutral generic plural form of "you" (which is itself both singular and plural).

No clue what that is. I do an acronym search and none of them fit your context.

YES. Kind of like the word "dude" and our past discussions regarding its use.

Many other forums don't allow ANY posts with LINKS until AFTER the member has posted a certain number of posts. This guy has one post and will never log in again. He got exactly where he wanted, to post one link then move on, never to be heard from again.

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!).