NotHereToPlayGames

Links updated in first post.

I cannot "appease" everybody! When I first started sharing my home-use 360Chrome for others to benefit, I disabled webgl !!! But 7 out of 10 "this web site does not work" were all related to webgl -- so I have enabled it by default because the MAJORITY of users (at the time) "needed it" for their want-to-work web sites to work. MSFN is comprised of smart people. Those that want webgl disabled, they know how to disable it. I cannot hold everybody's hand. Pointing out Swiftshader and Angle WebGL is patronising in my view! But that's because we've been down this road before. A dozen times. Always by people that have Vista listed in their MSFN Profile as their OS. But fair enough, maybe you weren't here when we already went down this road. A dozen times. Perhaps some form of not knowing history being condemned to repeat it. Because this topic has been discussed. A dozen times. Bottom line - no one upload is going to "appease" everybody and no, I'm not going to upload 18 different versions. The userbase knows that I used to, one upload for webgl enabled, one for webgl disabled, one for translate function enabled, one for translate function disabled, et cetera. But no, I'm not going to do that, if users want webgl disabled, they all already know how to disable it. </end rant>

Agreed, this is just a STIRRING OF THE POT. The webgl vulnerability was addressed in Chrome v85 and we are running v86. It has become "mainstream" knowledge on just which MSFN Members post in this thread for the sake of improving 2044 because we use it. It has become "mainstream" knowledge on just which MSFN Members post in this thread for the sake of "naysaying" and because they don't want anybody else to use it since they themselves do not use it. MSFN is comprised of very smart users, we didn't land here because we are "dumbed-down" Lemmings just following the crowd (though MSFN does have a large number of Lemmings just "following" their 'leader'). For some of us, that means "hacking" Vista (EOL 2017) using Server 2008 (EOL 2020) "patches". I will not waste my time pointing out the vulnerabilities that hit the scene in 2021 and 2022 that even these Vista folks remain "vulnerable" to! For some of us, that means very different things than what it means for the Vista Group (we all know who you are, your "agenda" has become mainstream knowledge). MSFN is not here for Vista users to convert all XP users to run Vista. Or XP users to convert all Vista users to run XP. Or Win10 users to convert XP+Vista to run Win10. Moving on... I've no desire to constantly "fight" with the Vista Group always bringing themselves front-and-center.

On second thought, to anyone with knowledge of aforementioned "unsupported Service Pack", can you please PM me a link to it? It would be a nice "nail in the coffin" if I could demonstrate a working before versus not working after with the ONE variable being the installation of this "unsupported Service Pack". edit - I even have a Vista-era laptop and will install Vista + "unsupported Service Pack" on real hardware versus a VirtualBox VM just to put a nail in this coffin and bury it forever.

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.

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.

How long did it take your audio to die? Was it only with 2044 or did you also have this in 1030 or 2036?

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.

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.

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.

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.

Vista Ultimate SP2 x64 installed. Windows Defender activated. 360Chrome 2044 working as expected. Still working on updating through September 2012 (I do not support post-EOL "patches", be it XP or Vista).

I'm unable to replicate the Insecure Connection translation error. Can you provide a URL where this occurred?

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.

Strictly from Speedometer 2.1 with only one run each -- 2044 scored 75.5... 1030 scored 75.2... 2036 scored 74.8... This is on XP x64 on a fairly old i7-4770 @ 3.4 GHz with 16 GB RAM. So if we really want to "squeeze the turnip" for every last tiny drop of performance, seems 2044 is the "fastest". But those numbers are so close that we really are technically "within margin of error". I'll try a few other benchmark just for curiosity.

Not yet. I've been using 2044 for three days. Non-stop here at work (Win10 x64 monitored by Global IT) for 9 to 11 hours plus another 2 to 3 hours at home (XP x64) plus 1 to 2 hours at home (Win10 x64). While our Global IT isn't exactly the smartest of the bunch, they have issued ZERO "nastygrams" and they would within an hour if something didn't "look right". Technically the "monitoring" is fully automated and "notifications" are issued to IT by those automated "scans". If Global IT were notified by any of the automated scans, my computer would literally drop to email only with limited access even for email until "resolved". While I prefer to stay off that "radar", I have been running 2044 here at work with ZERO "nastygrams" from Global IT. While I respect the Vista x64 "warning", I personally trust our Global IT "monitoring" over and above whatever is causing this on Vista x64. Sure, if we can find a fix, I'm all for it. But it is not a deal-breaker for me and I also don't think it is for the majority of our userbase (which is quite TINY, as far as that goes). 2036 was only slightly slightly slightly less performant than 1030. Real-life noticeable? NO! Only noticeable by benchmark scores but essentially "within margin of error". 2044 seems to equal 2036 in all regards as far as benchmark scores. I don't see myself dropping back down to 1030. While 1030 was perhaps the "peak", it's all technically "within margin of error". I don't parse the Chinese revision mods from one release to the next. I do have to kind of "assume" that there was a REASON they upgraded 1030 and that there is a REASON they are at 2044. I don't know those REASONS nor "pretend to". So 2044 is quickly becoming my DEFAULT. But sure, I'm all for additional improvements. I have not looked into 2044 versus 2036 ClearType differences. I do not use ClearType and actually see this as an advantage for 2044 over 2036. I plan to attempt to recreate the ClearType difference on XP with ClearType enabled, have not done that yet.

Nope. I modify the files before ever launching. I only launch the files after copied into a fresh VM clone that is deleted and re-cloned from virgin OS before the next trial-run. Network traffic is monitored, there is none. This is some sort of "local non-internet-lookup integrity check" that only affects Vista x64. And as far as that goes, only two Vista x64 users have reported this (both of which have said in the past that they have moved on from 360Chrome). Or did they? If the Vista users WANT 360Chrome 2044, that is one thing. I'd hate to think that we (myself included) have HIJACKED this thread with this "trojan scan" non-issue to those that use 360Chrome daily on XP and 10.

Thanks. That is helpful.

More importantly, this is showing up with a 1030 Chinese ONLY when mix-and-matched and is also showing up with a 1030 Russian Repack ONLY when mix-and-matched. But both work perfectly fine without any mix-and-match. As far as the error that @rereser discovered during a mix-and-match (which is not 100% identical to the error @Dixel is getting), it is not "new" and it is not because 2044 was direct from Chinese without a Russian Repack base. The version of the error not requesting a download SEEMS TO BE only given to extended kernel Vista users - at the bare minimum, can the Vista Group at least acknowledge if they are using an extended kernel ??? So far all they have revealed is that they are running Vista x64. I have demonstrated no issues in Vista x86. I'd hate to have to prove that everything ALSO works in Vista x64 only after that time-waste be told "oh yeah, we run an extended kernel". Seems FAIR to me. Does the Vista Group even WANT to run 360Chrome in the first place? If the answer is "no, we're only here to cast shadows of doubt on your project", then why are we even discussing this? Signing off... Toodles for now...

Shows up even if offline. But ONLY if I mixed-and-matched. It's only fair that if I continue to spend this much time on this error, it is perfectly fair to request that you see if this happens for you on an OFFICIAL version of Vista x64. No patches or hacks, no extended kernels. Because as this currently stands, this is ONLY happening to those that the rest of MSFN suspects as running an extended kernel. It is FAIR to ask/verify/test if this is an extended kernel issue and not a 360Chrome 2044 or Vista x64 issue. I did test in Vista x86 and had no error. I was unable to install Vista x64 in a VirtualBox VM - but I did spend the time trying and it seems fair to me that if the Vista Group seeing this error truly wants this working then we need some time from them.

One sec...

1030 throwing that warning when 2036's 360chrome.exe was mix-and-matched:

I don't think you've followed the entire conversation. NONE of us get the trojan warning when running AS-IS. We ONLY get the trojan warning if we MIX-AND-MATCH files with this version and MIX them in with ANOTHER version. This has been the case with ALL previous versions. This is nothing "new" to only 2044. Many love 1030 (myself included), it too throws this "trojan warning" if a DIFFERENT version's chrome.exe is MIX-AND-MATCHED in with it. We should NOT be mixing and matching anyway, so there's really nothing to "fix" other then a "stern warning" - Please to not mix and match. I'll screen cap in a second, I can't have "both" open at the same time.

Confirmed. But this has always been the case, you can't use one version's .dll with another version's .exe. Aside from fixing the broken English, this only occurs when one "mixes and matches", I see no need to prevent the no-start for a mix-and-match. Although I can see an advantage in removing the "yes" button when it requests to download a new version and display only the "no" which forces an exit with no ability to launch. Folks that create their own loader would have to create their own integrity-check. A loader from 1030 will not load 2022, 2036, or 2044 - nor should we expect it to. Those are the only versions I just attempted a mix-and-match. I wouldn't WANT them to load under a mix-and-match, to be honest. There really are a TON of things shuffled around and indexed differently post 1030. In my view, 13.0.2206 and 13.5.1030 were kind of the best it got for 360Chrome. 2206 was reported to have issues on some systems, it was nothing but stable for me. Stylus extension did have some stability issues with 2206 when editing stylesheets. 1030 seemed to be the most stable across a larger set of systems and none of my extensions had any issue with 1030. If I were to pick "one version for everyone", I'd actually pick 1030. That said, sure, it's nice to have the "most recent" but sometimes I think we just fool ourselves into thinking the "most recent" is somehow 'better' or 'more secure' or this or that.

I've not experimented with it yet. Have you tried "chrlauncher"? https://chromium.woolyss.com/ (grab any of the "portable" links then replace internal contents with any Chrome-based browser, including 360Chrome) Will 360Chrome's own "cache location" solve your needs? chrome://settings/advanced (third entry in right column)