Jump to content

ArcticFoxie/NotHereToPlayGames -- 360Chrome v13.5.2044 rebuild 2


Recommended Posts

17 hours ago, NotHereToPlayGames said:

All three of these benchmarks say the same thing - that 1030 is faster then 2036, but that 2044 is faster then 1030.

But the scores are so close together that if I had the time to average 100 scores instead of only 3, then all three may very well merge to the exact same score.

These scores do not offer any statistical reason to run one version over the other.

image.thumb.png.c93400f66236a04a49ea550121253ce4.png

Thanks, interesting! And what about your famous cold boot 29 seconds slowness? Is it the same with this version on all of your computers?

Link to comment
Share on other sites


19 minutes ago, Dixel said:

And what about your famous cold boot 29 seconds slowness? Is it the same with this version on all of your computers?

It's 20 and not 29, but who's counting.  Actually, it's anywhere from 12 to 20.  That cold-boot issue is ONLY if I "rebase" (which you will note that I have not provided any "rebased" 2044).

x86 operating systems will likely "need" to rebase.

But yes, a rebased version will always present that cold-boot slowness on my x64 systems.

But let's not put that out of perspective - New Moon and Mypal takes 30 to 35 seconds on the same x64 systems!  I have not experimented with "rebasing" them (they are of technically no use to me).

Official Ungoogled Chromium v114 takes 25 to 30 seconds on the same x64 systems!  I have not experimented with "rebasing" Official Ungoogled Chromium v114.

If I do NOT "rebase" then my cold-boot time is under 4 seconds.  I use PassMark AppTimer for a repeatable timing, not some stopwatch that would be biased by unconscious reaction time tilting favor this way or that way.

4 seconds is phenomenal and above average on my old systems (these times are on my dual-core for worst-case scenario).

Chromium v49 (March 2016) took 6 to 10 seconds.  Official Pale Moon 27.9.4 (July 2018) was also in the 6 to 10 seconds range.  "Rebasing" was never a topic way back then.

NOTHING "loads instantly".  PassMark AppTimer seems the best quantifiable measurement for this purpose.  A gui being "visible" is not the same as the gui accepting keystrokes.  NOTHING "loads instantly".  NOTHING.

Link to comment
Share on other sites

23 minutes ago, seven4ever said:

I aggree. It was not the subject of my fist post, it was about translation issue.

Correct.  A "green padlock" is NOT possible in XP.  NEVER WILL BE for several new security certificate types.  This has been discussed "ad nauseam".  XP users are aware of this.

Link to comment
Share on other sites

3 hours ago, NotHereToPlayGames said:

Correct.  A "green padlock" is NOT possible in XP.  NEVER WILL BE for several new security certificate types.  This has been discussed "ad nauseam".  XP users are aware of this.

Maybe need to  add to the topic's description, I feel people will still ask the same question over and over again, @Cocodile explained this has nothing to do with this browser.

Link to comment
Share on other sites

3 hours ago, NotHereToPlayGames said:

Official Ungoogled Chromium v114 takes 25 to 30 seconds on the same x64 systems!

It's not normal, esp. for ungoogled, I read this odd delay maybe tied to the video driver, esp. outdated.

For XP the golden drivers are the ones that made by iCafe. 347.26, 361.77.

Link to comment
Share on other sites

Quite possible.  Ungoogled has no cold-boot delay at work.  But 360Chrome is my default-for-everything (at least for now) and since it does not have this delay so long as I do not "rebase", then it's kind of a mute issue for me, to be honest.

ps - Ungoogled Chromium v114 has the cold-boot 25 to 30 second delay for Win10 here at home, one cannot run Ungoogled Chromium v114 in XP.

Edited by NotHereToPlayGames
Link to comment
Share on other sites

I am "between a rock and a hard place" as far as the Vista "trojan scan".

I have demonstrated that this is NOT an issue on OFFICIAL installations of Vista x86 and Vista x64 (VM versus real hardware should not matter in this case).

There are only the TWO "checks" and they are EASILY defeated.  One where it simply exits (Dixel) and one where it requests to download latest version (rereser).

These "defeats" are not complex, but we also tread a fine line on just how much we "edit" and then upload for "public use".

Correcting the broken English isn't really the concern here (also EASILY achieved), "defeating" the 'check' is what seems to be at play here.

I do not think that is actually "allowed" here at MSFN.

I would prefer a chime-in from @Dave-H or @Tripredacus before I start uploading the types of "edits" that DEFEAT the original programmer's "integrity checks". 

Especially when thus far it has been cited that only an "unsupported OS / Service Pack" seems to be the common denominator here.

 

image.thumb.png.fbe7a12ff803209f8b933a757532b06f.png

image.png.fdcdae1be872ba8267cb9e47c4dac946.png

Link to comment
Share on other sites

I've always had delays after cold boot with bigger software, regardless of Windows version. Vista and 10 (presumably 11 as well) seem more dedicated at preloading everything they can in RAM, so if you've got the prefetcher trained to load the right files, it could be faster when you launch it if you wait a while after boot/resume from hibernation.

Vista+ will always pick another base address for executables with ASLR flag, the process in this case is simply more intelligent as base address will be shared among same module in case of multiple instances of the process that loads said module so it won't waste extra memory like in XP.

Allocating memory at higher addresses tends to be slower than allocating at lower addresses (architecture thing?), this likely applies to memory-mapping files in memory, which would explain higher delay when manually rebasing DLL at higher address.

18 minutes ago, NotHereToPlayGames said:

I am "between a rock and a hard place" as far as the Vista "trojan scan".

I didn't have this error when messing with 360Chrome on Vista. But when using that browser, audio eventually died system-wide and I had to restart Windows Audio service. It gets old after a while.

Edited by UCyborg
Link to comment
Share on other sites

39 minutes ago, NotHereToPlayGames said:

How long did it take your audio to die?

I honestly don't rememember exactly. Must have been at least 1h.

39 minutes ago, NotHereToPlayGames said:

Was it only with 2044 or did you also have this in 1030 or 2036?

2022 :P

Link to comment
Share on other sites

1 hour ago, NotHereToPlayGames said:

I am "between a rock and a hard place" as far as the Vista "trojan scan".

I have demonstrated that this is NOT an issue on OFFICIAL installations of Vista x86 and Vista x64 (VM versus real hardware should not matter in this case).

There are only the TWO "checks" and they are EASILY defeated.  One where it simply exits (Dixel) and one where it requests to download latest version (rereser).

These "defeats" are not complex, but we also tread a fine line on just how much we "edit" and then upload for "public use".

Correcting the broken English isn't really the concern here (also EASILY achieved), "defeating" the 'check' is what seems to be at play here.

I do not think that is actually "allowed" here at MSFN.

I would prefer a chime-in from @Dave-H or @Tripredacus before I start uploading the types of "edits" that DEFEAT the original programmer's "integrity checks". 

Especially when thus far it has been cited that only an "unsupported OS / Service Pack" seems to be the common denominator here.

I wouldn't have thought that disabling integrity or security check warnings was a good idea on principle, unless it was absolutely necessary to make the software usable.
From what I've read here, the warning would only impact people if they messed around with the files!
I certainly wouldn't ever expect to see it.
:D

Link to comment
Share on other sites

I'm opting to leave the "integrity check" UNALTERED.

Everything is working just fine for me in XP x86, XP x64, Vista x86, Vista x64, and 10 x64.

All fully updated with archived "AutoPatcher" which was (may still be, unknown) an automated downloader that fetched all LEGIT hotfixes directly from Windows Update when said hotfixes were still provided by Windows Update.

Anything "unofficial" as far as Operating System "updates" are of no interest to me.

Link to comment
Share on other sites

@NotHereToPlayGames
It's posible this only started with enough system uptime or hibernate/resume cycles. Since there are longer periods between messing with older systems, memory gets fuzzy. Last fresh boot of Vista was in January 2023 while I put the 360Chrome there in December 2022, from that point backwards, it was months since last fresh boot, it could be that I'm remembering the issue from between December 2022 and January 2023. What I do remember clearly is trying to see if Vista is any more resilient in that regard on my system with my usage patterns and it turned out eventual reboot is in order, like with newer MS OS. It takes 2 or 3 months easily on any OS before something odd happens, so can't say any system is better or worse than the other. It's not something I attempted with XP because this OS starts getting on my nerves in less than a single afternoon due to certain technical limitations.

I have 360Chrome running for 1 hour now and sound still works...played a bit of Quake III (the web version) against the bots.

10 minutes ago, NotHereToPlayGames said:

I'm opting to leave the "integrity check" UNALTERED.

This is interesting, I thought it was supposed to be skipped anyway as otherwise you couldn't ungoogle it or do any mod of the executable files.

Edited by UCyborg
Link to comment
Share on other sites

I've never actually had to skip or modify the integrity checks.  How "extensive" those checks are, I did not decode.

But I have compared official upstream original code with even the Russian Repack code and even the Russian Repack releases made no modifications to these integrity checks.

Mixing-and-matching ANY of the versions (including Humming Owl's) will throw one of the integrity-check warnings (which should be EXPECTED).

The exact warning that Dixel and Cocodile are getting has yet to be reproduced on any Vista system using official Microsoft updates.

It has been reported that an unsupported Service Pack is being used and I'm not going to install an unsupported Service Pack for the sake of reproducing a warning I have been unable to produce otherwise.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...