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

[D.Draker]

3 hours ago, NotHereToPlayGames said:

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.

Thanks ! You don't have to install anything for Vista, just put the dll into the opera folder and you're done ! This works up to chrome 109.

110 and onwards only works with my hacks (hard butchering) . I don't know why you all is so against this word . Does it sound too rough in English for your ears ?

I don't know about win 7 and don't use it. The reason I wrote is - I suggested to use CFF.

[NotHereToPlayGames]

12 minutes ago, D.Draker said:

Does it sound too rough in English for your ears ?

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

[NotHereToPlayGames]

13 minutes ago, D.Draker said:

I suggested to use CFF

No clue what that is.

I do an acronym search and none of them fit your context.

[D.Draker]

3 hours ago, NotHereToPlayGames said:

No clue what that is.

I do an acronym search and none of them fit your context.

It's because the search function is crap here. The word crap is also too hard ?

I'm sorry, I don't know how to use soft English. We here call things for what they are.

CFF explorer I used in my tutorials :

https://ntcore.com/?tag=cff-explorer

 

[UCyborg]

On 12/27/2022 at 11:15 AM, NotHereToPlayGames said:

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

Only those that have DLLs loaded in other applications.

It might be unrealistic to be able to make public release with the "perfect" alignment, I think avoiding the popular 0x10000000 is good enough start, you basically want to avoid that huge DLL from being rebased by the OS, it has to be first to occupy its space. If you use some debugger, you could pause it at the point chrome.dll is loaded and see what's free.

With public releases of software in general, it's probably unavoidable that a DLL there or there is rebased, but the issue is smaller with smaller DLLs.

AFAIK GCC for Windows uses some own logic to choose address for DLL when building, eg. compare DLLs of T-Clock Redux, one version with built GCC, another with Visual C++, latter has MSVC default address while the other has it in the high range 0x60000000.

NVIDIA's driver DLLs (at least I checked OpenGL one) for instance also has a high address in 0x60000000 range, but I doubt NVIDIA used libre compiler, so must have chosen their own / put it with others through REBASE.EXE with high starting address or something, who knows, not much about rebasing written or I haven't searched thoroughly enough. Mentioning because I rebased DLLs of the other browser and forgot about WebGL initially, which loaded OpenGL driver, so my first chosen address ended up in a conflict with the driver DLL, which had to be relocated.

I actually went with a bit lower address for chrome.dll, I can post it when I get home. There might be something about loading delay with high address and big DLL here too, not sure, my XP is more sluggish on some days at startup than others.

Since YouTube often comes up in these browser discussions, neither the new test version of ImprovedTube extension nor current version of Enhancer for YouTube are compatible. Funny thing about ImprovedTube, not sure it's legacy OS thing / something missing in them (who knows what...), but even the last working version has an issue that buttons labels in main menu are missing and the picture buttons are bigger because of it.

Edited December 28, 2022 by UCyborg

[NotHereToPlayGames]

1 hour ago, UCyborg said:

neither the new test version of ImprovedTube extension nor current version of Enhancer for YouTube are compatible

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.

[UCyborg]

I suspected it's something like that. So this browser is just two versions away from Manifest V3 (https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html).

[Sampei.Nihira]

MV3 timeline appears to be postponed:

https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/

[UCyborg]

Alright, tested the load time of browser again after Windows startup and after the other startup programs have loaded. All on already good warmed up PC, well, as warm as it can get when the ambient temperature is about 15 degrees Celsius or so does my thermometer say.

I can confirm approximate 4 to 5 seconds delay with rebased DLL here after 3 tries. Very curious. Now who can explain that?

I save load of RAM with rebased DLL, if I take 14 same tabs, we're talking total RAM consumption of the entire system of 1,4 GB vs 3 GB. Chrome loves multiplying its core process you know, it's not just the first 800 MB and some, assuming you open a bunch of tabs.

Funny you mention walking to the other higher end PC @NotHereToPlayGames, what about boot time of that PC or are we talking about PC that's already on? 

BTW, I got chrome.dll at 0x3E1C0000 now. LOL, this whole thing feels like DOS all over again.

Edited December 28, 2022 by UCyborg

[NotHereToPlayGames]

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.

 

[AstroSkipper]

Hello @NotHereToPlayGames! Since I was the one who discovered and documented the abnormal RAM consumption of the 360Chrome browser in Windows XP, for which I received extremely friendly comments in this thread at the beginning, then called for further investigations and researched the causes, I will now take a look at the state of play.
First, the good things.  For all Windows XP users who really need this browser, i.e. who want or need to run old, low-powered hardware for which this Windows OS is the last compatible one, the method of rebasing the chrome.dll is an excellent stroke of luck to put an end to the memory hunger of this browser. Thanks again to @UCyborg and @mixit for their tips! I have now rebased the chrome.dll file in all my 360Chrome installations. I was able to reduce the RAM consumption of 360Chrome 13.5 build 2022 by almost 85%. That is truly enormous. It's almost beyond belief! 
Now, the bad things.  For me, the time it takes to start a browser is totally unimportant and frankly irrelevant. What is much more important is the loading behaviour of websites in general when the browser has already been started. And that's where this browser doesn't look good at all. Many websites take eternities for being loaded if at all. It is not uncommon for the endless loading process to end in an error page. Not comparable to @roytam1's UXP or moebius browsers at all! That would be much more of a cause to be concerned. 
Anyway! If I were you, I would leave all 360Chrome editions for users of Windows Vista and higher as they were. For Windows XP users, however, I would offer a separate version in which the chrome.dll file has been rebased in any case. The reason for such a procedure is the ASLR feature, which all Windows versions from Vista onwards have, but unfortunately Windows XP lacks. On the subject of rebasing, you can certainly test which address is best suited for this procedure. Personally, I have done it automatically with libase. And that seems to be sufficient, at least for me. However, I hardly think that this will improve the loading behaviour of websites on old, low-powered hardware. In any case, I couldn't notice any improvements in the loading behaviour of websites on my system. This is probably more of a browser-specific problem which presumably can't be solved without further measures as for example recoding, code changes or code optimizations.  And I doubt that 360Chrome 13.5 build 2022 is the best suited version for Windows XP. For example, 360Chrome 13.5 build 1030 seems to be better suited as far as I can observe in my case, according to the 360Chrome rule: the newer, the worse. 

Edited December 29, 2022 by AstroSkipper
correction

[NotHereToPlayGames]

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.

[NotHereToPlayGames]

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

[AstroSkipper]

2 minutes ago, NotHereToPlayGames said:

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

I have also already downloaded the ReBase tool from the Windows SDK. When I have time, I will try that out as well. 

[NotHereToPlayGames]

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