NotHereToPlayGames

So now we are just battling for the "last word". So I'll bow to your expertise and assume this very post "doesn't count". waka waka waka

Not really. What do you honestly think would be "expected" of roytam1 if it was discovered that Basilisk/Serpent used "half" as much RAM if one of the .dll's were rebased? I myself think that the roytam1 user-base would NOT be expected to perform the rebase, but rather that roytam1 would be expected to do the spoon-feeding and provide the next weekly release with that rebase included.

But then again... I used to get the feeling that a TON of people "use" roytam1's WEEKLY offerings - and that they even sit on the edge of their seat each and every week in anticipation of the next WEEKLY offering. I say "used to" because nowadays, I honestly see roytam1's offerings as very very VERY similar to the 360Chrome offerings here at MSFN - ie, a very very VERY "niche market" and a very very VERY "dying breed".

It's not about being something everyone can do. I feel very confident in claiming that if it were discovered that any of roytam1's offerings has the same RAM-consumption improvement just by running a CMD command on "one" of said roytam1's offerings' files, then it would be expected by the roytam1 end-user that roytam1 perform that CMD command before uploading his next offering. Very confident.

Technically, that address isn't "chosen". Libase "generated" that address because the end-user opted to use StartBase=0x60000000 in the .ini file. The "generation" is an algebraic equation ran on the file name (chrome.dll). Change the name to xchrome.dll and you'll get a different "generated" start address. Change the name to chromium.dll and you'll get another different "generated" start address. The StartBase=0x60000000 is plucked out of thin air, a typical start address for file names beginning with the letters a, b, and c. But outside of the "spelling" of chrome.dll, there is no real "reason" to use StartBase=0x60000000.

Providing a "bat file" isn't really the solution. Every end-user is best served by reading the discussion and performing their own rebase. No "one" 'fix' is going to work on all computers. At least, I don't think so "yet". So far, rebasing to 0x10010000 has worked on everything I've tested it on (six different computers, all XP, some x86, some x64). But then again, I had 0x3e1c0000 working on all six of those computers also but users on the forum cited "freezes" with 0x3e1c0000. Would be interesting to hear from those where 0x3e1c000 caused "freezes" - does 0x10010000 also cause freezes? Because ultimately it would be nice to have an address to rebase "distributions" to without freezes.

And mileage may vary. Libase did not work for me. I had to use REBASE.

Rebase.exe works better for me. Don't worry, you don't need to spoon-feed me.

I have since been rebasing mine to 0x10010000.

Nope! But did discover that you can DELETE the Updater.dll file in the plugins folder and whoala, no more phone-home telemetry (or disable via plugins menu but this would allow it to phone home "once" because you had to launch with it enabled by default).

I already have it blocked via firewall. I still prefer software versions that don't contain such telemetry to begin with.

But that version "phones home" (ie, TELEMETRY) at least once a week (that's the only time period I checked). You can witness this by setting your clock forward eight days then watching DNS traffic when you launch Process Hacker. I personally try to avoid any-and-all of these "hidden" types of network traffic.

<OT Rant> So here I am, minding my own business, doing my own thing, experimenting with chrome.dll, and BAM, I'm hit in the face with a d@mn "update available" POS nag screen! So now I'm diverted from the project-at-hand (chrome.dll) and have to experiment with Process Hacker instead, which was NOT my plans for the day! edit - and no "do not check for updates" preference setting anywhere to be found! in other words, built-in automatic PHONE-HOME TELEMETRY! Preferring to be working on chrome.dll, I did not experiment with Process Hacker for too long. But the d@mn POS nag screen INFURIATES ME BEYOND NO END! So, without further adieu, I present to you a Process Hacker version without the d@mn "update available" POS nag screen. There may be others, or even "newer", but this was my FIRST guess and it does NOT have the d@mn POS nag screen -- v2.19. Available here -- https://sourceforge.net/projects/processhacker/files/processhacker2/ </OT Rant>

AGREED! Well stated! I have often stated that 360Chrome is "intended" for the XP audience and there are far more alternatives available to the the non-XP crowd. I "sometimes" still use 360Chrome on my Win10 installs, but only for the sake of a shared "profile" and not because 360Chrome is the best "choice" for Win10.

Got it, thanks.

I'd have to jump through the hoops all over a second time, but I don't seem to recall LiBase even "working" on my system. I had to use ReBase and experiment with the actual start address. Whereas LiBase had no option for start address (that I recall).

Did you also try "ReBase.exe"? Or did you only try "libase.exe"?

Correct, I've seen it for a few months. But the problem is there is never really a "final" v13.5. I kinda don't plan on updating build 2036 only for upstream to release another build weeks later. Not a fan of dog chasing its own tail with all of these "updates". It would be one thing if we could isolate actual WEB SITES that work in build 2036 but that do not work in build 2022 or build 1030.

UN-REBASED first-launch-after-hibernate on my oldest XP x86 -- 13.5 build 1030 versus 13.5 build 2022 -

Agreed. And I just double-checked, I have been running site isolation for the last couple of weeks. "Spectre" mitigation is ZERO priority as far as my browsing needs. But now with Cloudflare not liking it, I did switch it back to default on my setup. It is a "balance", I'd rather consume more RAM but be 100% functional. Not "everything" boils down to RAM in my book. edit - I also switch to UN-REBASED build 1030 as my default. But it seems a splitting-of-hairs between it and 2022.

Yeah, my bad, I was experimenting with some flags and didn't intend to upload with that flag set. That flag does decrease the number of processes and thereby cuts down on RAM but I don't run that flag with my default config.

Yeah, I was kind of afraid of that. Rebase address will be heavily dependent on the end-user's system.

I actually prefer the NON-REBASED build 2022. Fast-as-possible launch coming out of hibernate trumps the extra RAM for my preference.

lol. You preferred 1030 over 2022 so that was one of the driving factors to release a 1030.