NotHereToPlayGames

Regarding the "likes" that seems to keep coming up. I would encourage my FRIENDS (they know who they are) to please please please not "focus" so heavily on "likes". Your life is NOT reduced to "likes" or "followers". The "psychology" behind thinking that way has been directly linked to teen suicides (and buried in inter-office board-room memos by very large social-media companies that live-and-die by "likes"). Please please please do not "focus" so heavily on "likes". Carry on, my FRIENDS. But I did want to throw that tidbit your way.

I've been using build 1030 as my default for about a week or so. I don't recall what base address was used by @UCyborg - I've been using 0x1001000 for both my x86 and x64.

We generally refer to that as portable also. Some (but I am not one of them) do not classify WEB BROWSERS as "portable" unless ENCRYPTED COOKIES AND LOGINS also migrate from one PC to the next.

No disagreement here. Just saying it's not exactly "black and white". This old dinosaur drives a '55 Dodge Coronet, a '61 Studebaker Hawk, a '90 Eagle Talon, and a '91 Dodge Stealth R/T.

I don't think we can really make a blanket-statement such as that. These "new standards" are not 'always' more cumbersome and heavy on loading. Some javascript functions were created out of necessity for "efficiency". "New" ways of doing things are sometimes "better". If we "parse" the full list of javascript functions "introduced" in 2015 and compare directly with the "old way" of doing the same function, I bet we will find that "newer is better". And if they are not, then at least the non-lazy web developers would still be using the "old way". But unfortunately, in this cookie-cutter world, "non-lazy" web developers are few and far between.

Agreed! However, I highly disagree with the term "Googlized" - that's just a fancy Mozilla Term in my book, some sort of "blame Google that we cannot render your web site". That "blame game" doesn't really work, in my opinion. ECMAScript 2015 is the "standard" to which javascript engines have to comply in order to render "modern" web sites. Available here -- https://www.ecma-international.org/wp-content/uploads/ECMA-262_6th_edition_june_2015.pdf There are newer standards, but for the sake of the term "Googlized" that gets thrown around here at MSFN, I'll refer to the 2015 standard. I do not know what the newer standards bring to the table, but I do know that import, optional chaining, and nullish coalescing has been around since 2015. 360Chrome v13/13.5 is a 2018 web browser and it complies with import, optional chaining, and nullish coalescing operators. The actual "base" for most of roytam1's is a bit muddy for me, but basically circa Firefox 52 (March 2017), 53 (April 2017), or 55 (August 2017) depending on your reference point. 2017 browsers should comply with 2015 standards. Will another two+ years of weekly updates on roytam1 offerings achieve better "compliance"? Your guess is as good as mine. Optional chaining and nullish coalescing operators were not in compliance two years ago and are today in some of the roytam1 offerings. So yes, "progress" is being made. But my main point here is that Google does not write the "standard", they just do a better job at complying to the "standard". I am quite positive that ECMA International did not set out to create a standard that Google could comply with but that Mozilla could not. Market share is determined by who can best comply with web standards more then by brand loyalty. Mozilla does have this for them, they're like "pirates" - the ship may be sinking, but they will go down with that ship and stand proud while gasping in that last breath.

Perhaps... But I could list one by one "at least" a hundred web sites that WORK on this "no longer actively developed" 360Chrome but do NOT WORK on ANY of the roytam1 offerings. The last TWO PLUS YEARS of weekly updates have still YET to get any of the roytam1 offerings to "work" for any of those "hundred web sites". To each their own... I'm done for the night... I tap the mat and bow out...

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