Leaderboard

@Chuck : Also take note of the "workaround" posted by @rereser: https://www.xpforums.com/threads/360-extreme-explorer-chrome-69-for-windows-xp.934574/page-3#post-3269734

Also, going to see when I have the time to update all browsers with chrome.dll and (chrome_child.dll for the ones that use it) with a different preferred base address (probably 0x10010000) as RAM consumption gets reduced a lot when doing that. I will preserve the non-rebased DLLs in case something goes wrong. PD: Thanks to @NotHereToPlayGames for pointing it out.

Certificate issues are always going to be a problem with XP. It is something related to XP not having support for some newer certificate types. These browsers were not built to treat those certificates issues so you should expect these problems to vary between browser versions and different websites. There are some tools to manually update XP certs as the one @VistaLover pointed. You may be able to fix some of the certificate errors by using that tool. Cheers.

Notice: ( especially @adata and others ) Please don't report bug(s) of my browsers using forum's Message function (to me) unless you're providing login credentials for reproducing the bug, or your report(s) will be ignored.

It's been a while since I posted here...and a while since I tested New Moon 28. Though I'm a 360v13.5 'convert' and have moved on to that as my primary browser in XP, I wanted to use NM28 again, at least for a few days...seeing PaleFill brought up, which I have used with good results before, gave me a 'spark' to revisit this 'blast from the past'. I'm writing this from NM28 right now and can confirm both it and PaleFill are working great. It's funny because NM28 is built on fairly modern web technologies, and has gotten some nice improvements over the years to bring it more in line with newer, more capable browsers. And yet it feels very 'old-school' now, not just because of the vintage Pale Moon UI but having so much legacy code from the Firefox 52 days. Despite that, I am impressed to see what they can still do, and my appreciation for all of the years of fun I've had with old-school Gecko/Goanna/UXP browsers gives me the patience to deal with their flaws and limitations. We're a long ways removed from how things once were, so it's nice to have NM28 and other projects like it, to remind us of those 'glory days'. As long as possible, I hope these browsers can be kept alive. (Turn off JS, for sites that don't need it, and they still crush any modern browser in terms of speed.) Thank you for all you've done, Roy! You are one of the legends of this community, and I thank you for continuing to do what you do.

Elliptic Curve Cryptography (ECC) is NOT supported by Windows XP SP3, has never been, even with the POSReady updates... But some POSReady update(s) did implement native TLS v1.1/1.2 support in XP - don't ask me for further details, running Vista SP2 here... To update your XP Microsoft Store certs, see below: https://msfn.org/board/topic/183352-proxhttpsproxy-and-httpsproxy-in-windows-xp-for-future-use/

Also, unless I'm mistaken, you run XP x86 SP2. XP x86 SP2 was released in August 2004!

Yes. Chrome/Chromium support for CSS 3D pre-dates v86 by over a DECADE. Chromium v86 was released 06/10/2020 (day/month/year, I sure as Hades wish there was a universally-accepted date format!).

In my quite clean testing profile, I opened your testing repo and performed continuously soft reload. After more than 20 times I stopped. In this profile, setting both dom.webcomponents.enabled and dom.getRootNode.enabled to the value true with Palefill 1.26 enabled works on your testing repo, i.e., GH timestamps are shown each time. In my main profile, unfortunately not as I already mentioned in a previous post.. However, these strange differences between my profiles keep bothering me. And I have to correct my statement from a previous post which I already edited. You're right, setting dom.webcomponents.enabled to false does not lead to a 100% CPU utilization on GitHub (but on VirusTotal ). The site was continously loading the assets from the not visible part down below. Scrolling down to the assets normalized the CPU usage. I didn't notice that in my first test. So theoretically, I am able to set dom.webcomponents.enabled to false, but I'll leave it at its default value. In any case, I have to test all of that over a longer period of time. Best regards

As I suspected. You have WebGL enabled! So you seem to NOT be using the loader.ini CORRECTLY because you screencap'd that your loader.ini has WebGL "disabled".

We should not forget that there is a further tool for updating Root Certificates in Windows XP. The creator was @Thomas S.. The tool is called CAupdater. Here is the link to its original post: It is also embedded in his HTTPSProxy package. In his original post, the download link of CAupdater as a single archive doesn't work anymore. BTW, both versions of my self-created Root Certificate and Revoked Certificate Updater are meant to be used in case no internet connection is available. Generally, @heinoganda's Certificate Updater 1.6 or @Thomas S.'s CAupdater is completely sufficient. All facts about Root Certificates can be read in the section 5.2 of my article "ProxHTTPSProxy and HTTPSProxy in Windows XP for future use". Greetings, AstroSkipper

True, but not in the sense discussed here; in 360EEv11, navigate to "chrome://settings/advanced", then scroll further down to "HTTPS/SSL": If you press the top first button (Manage certificates...), you are presented with an OS window: a clear indication it's using the OS cert store... Now, if you click the third bottom button (with Chinese characters), you do get access to its built-in cert store, but that is only meant to be used within China, for mainly Chinese sites: What's more, the user has no edit access whatsoever to that cert store, i.e. expired certs can't be deleted, nor new ones be imported... FYI, all variants of 360EE (v11/12/13/13/5) have the same cert stores structure (access to the MS cert store + QiHoo provided one); more info about the QiHoo/360 cert store can be found at below link: https://caprogram.360.cn/#plan (in the header, select "English") Regards.

When using my Android tablet, and I use it very often (as for example in this moment), I haven't experienced such heavy CPU usage in Opera, Kiwi, Brave and Firefox, either.

I have downloaded the 5th link from the first page: https://www.dropbox.com/s/l3e5m48tzzb30bj/360ChromePortable_13.5.1030_r8_regular_webgl-enabled_translate-disabled_win-10-skin.zip?dl=1 Renamed file (to download) to: 360Chrome 13.5.1030_r8_r_webgl-e_tr-d_w10-skin Tests: chrome://gpu : WebGL: Software only WebGL2: Software only https://get.webgl.org/ : "Your browser supports WebGL" WebGL Browser Report: https://browserleaks.com/webgl : WebGL Support Detection This browser supports WebGL✔True This browser supports WebGL 2✔True (88 of 88) ...then click on the Escape map link: https://greatescape.co/map?departDate=2023-04-05&returnDate=2023-04-19 : map is here. So NO problems, WebGL works with this build, as expected...

... First press "Apply", then "OK", maybe?

It has also been reported on some forums that ECC certs in XP have been FALSIFIED as "secure" by some XP web browsers.

... How so? When you selected win2k compatibility mode in 360Loader.exe's Properties window, did you click "Apply" before clicking OK? That window looks as below under Vista (should be similar on XP): In any case, can't reproduce this here ...

I downloaded them from archive.org which are the links in the first post of this topic. It's all cleaned, only 180 mb maxinum of ram are used at startup. CPU is used only by browser and task manager.

In my opinion, one should NEVER "manually update" certificates. While other MSFN Members would equally swear the exact opposite as their opinion. I've NEVER updated my "certificates" and I have no problem whatsoever with the web site in question. Chrome/Chromium uses XP's "certificate store". I let XP manage that "certificate store". "Opinions are like butts. Everybody has one, not everybody wants to hear them."

... Another villain is below "Notifications wizard": to be found in the right GH "sidebar"... It's akin to the "Assets wizard" under GH releases page that you described; when you load a GH page containing either one, the wizards display (in the background) a constantly spinning circle, which consumes many CPU cycles ; the wizards don't display fully until you scroll past them (downwards or upwards), thereafter the CPU consumption drops (until you have to reload the page, that is ...) - this behaviour doesn't change whether you use the native WC implementation (palefill disabled) or palefill standalone (native WC disabled) ... NB: The Notifications wizard pictured above does not display at all when you browse GH being logged-out; the "Assets wizard", however, will still cause the heavy CPU usage until scrolled past... As one would expect , I haven't experienced such heavy CPU usage when using 360EEv13.x to browse GH pages containing those two wizards ... Regards.

Hi. The browsers tested has been just downloaded from archive.org so they contain no extensions and are launched without anything installed (that's what I meant for vanilla). I updated the system certificates again, though they has been updated 2 months ago, tried rebooting but still no https in that site on anything else then 360ee 11 and no images showed, tested in 360ee 12, 13.0, kafan minibrowser and DC browser (the last one I think will be my choice if I can get it to work because exhibits comparable performance with 360ee 11) To me 360ee 12 won't show images on that site too, anyway it's too heavy for my PC (for surfing and streaming at the same time) P.S. operating system Is windows XP SP3 with all security updates (no posready).

Oh, and I just noticed another bug: download https://eternallybored.org/misc/startallback/test.lnk, then just try deleting the file – if StartAllBack is installed, Explorer will crash (the shortcut is old UWP Edge shortcut from Windows 10).

My primary browsers in Windows XP are New Moon 28 and Serpent 52/55. I use 360Chrome 13.5 only for testing purpose in my Windows XP installation. It is great to have alternatives but I prefer UXP browsers under Windows XP. I am also an Android user, and there you have a pure Chrome/Chromium world offering the most recent browsers. Or I use Windows 7/10 to surf the internet with the more/most recent Chromium browsers. But no need to do that in my beloved Windows XP system, and 360Chrome 13.5 is not recent anymore, either. When starting my Windows XP system, I dive into another world and enjoy the recreation of all this Chrome/Chromium stuff. All Chromium browsers are extremely restricted, especially in terms of extensions, custom buttons, customizations and modifications. That's one of the reasons I love and prefer my UXP browsers New Moon and Serpent. And to have them at all, I am very thankful to our creator @roytam1! Welcome back and of course, a good decision! Cheers, AstroSkipper

Did you try in an INCOGNITO WINDOW? And without setting any extensions to be allowed during Incognito Mode.

You have your files criss-crossed and you confuse the flow of this thread until that criss-cross is resolved on your end.

... For starters, you shouldn't do that (when testing), as palefill conflicts/interferes with native WC: https://forum.palemoon.org/viewtopic.php?p=237202#p237202 From Moonchild himself: Second, I have always been talking about Serpent 52 (actually, its previous version of 2023-03-02); but just to humour you and be on the same ground as you, I did launch a quasi-fresh profile of latest NM28 [v28.10.6a1 (32-bit) (2023-03-10)], where I installed and enabled palefill-v1.26 and then restarted it, for good measure... My GitHub testing repo this time is https://github.com/violentmonkey/violentmonkey/commits/master At first load, the relative timestamps do appear (in the "hours" range) - this is now with both palefill+native WC enabled, as you suggested; now try and continuously soft reload that page (by clicking the "reload current page" toolbar button); soon enough you'll get (I did, on my 5th attempt ) the missing timestamps bug: If, like me, you spend hours inside GitHub, then you "can't miss it"; this bug exists, as I've tried in fresh profiles (mainly St52, but lately NM28, too) and combinations of: a) native WC+SR enabled, palefill disabled (recommended by Moonchild) b) native WC+SR enabled, palefill enabled c) either of the two above, being c1) logged-in to GH or c2) logged out from GH The only combination (for me) where the relative GH timestamps remain permanently fixed is d) native WC+SR disabled, palefill enabled FWIW, with the above combination, the (latest) NM28 with fresh profile used to generate above screengrab consumes virtually 0 CPU when being minimised here: Conclusion: Everyone's setup may behave slightly differently, in a stochastic fashion , and this makes troubleshooting and fixing bugs quite a daunting task on the part of the devs ... Best regards.

Setting the preference dom.webcomponents.enabled to the value false in New Moon 28 is no option for me, unfortunately. Due to a permanent 100% CPU utilization on VirusTotal, for example, described in a previous post of mine. Therefore, this preference will stay here to the value true as long this abnormal behaviour exists, and presumably I'll just have to do without the GH timestamps in New Moon 28. Ok. I tested this GH timestamps behaviour a bit more deeply. It looks like I won't have to give up the GH timestamps after all. I've been using the extension Lull The Tabs for a long time in all my UXP browsers. This extension seems to interfere on GitHub sites which results in lacking of GH timestamps. Only disabling this extension or excluding the website GitHub.com in Lull The Tabs'options solves the problem. Edit: But only temporarily. There are more problems in my main profile. I need to investigate this strange behaviour much deeper.

https://greatescape.co/map?departDate=2023-04-05&returnDate=2023-04-19

StartAllBack 3.6.3

In MBR style disks the booting sequence is either: BIOS->MBR->PBR of active (primary) partitiion-> NTLDR (and NTDETECT.COM)->BOOT.INI->choice of OS or BIOS->MBR->PBR of active (primary) partitiion-> BOOTMGR ->\BOOT\BCD->choice of OS The "fixboot" command in XP recovery console simply re-writes the PBR (bootsector) code with the one designed to invoke NTLDR. The equivalent in a "full" system (Vista or later) is bootsect (with the /NT52 switch), NO idea if there is one in Longhorn nor which type of code it writes, some details on various versions: https://msfn.org/board/topic/171749-bootsectexe-various-versions-compared/ Since longhorn/shorthorn is midway between XP and Vista it is possible that the version you installed (that clearly needs to use NTLDR as it is fixed by the XP recovery console) *somehow* writes the bootsector invoking BOOTMGR and then Vista does not recognize the install (basically because there is no BOOTMGR not \boot\BCD. Third party, both bootpart.exe (by Gilles Vollant) and MBRFIX.exe (by Kaare Smith) should do (create a bootsector invoking NTLDR[1]), see also: http://reboot.pro/index.php?showtopic=5251 Something that you can try (as it costs nothing) is to make a copy of NTLDR and save it as BOOTMGR along NTLDR, very likely the bootsector loading code is the same for both. As a matter of fact at least in some versions of the boot code - on NTFS - it is possible to change the pointer to the string with the name of the loader as both strings NTLDR and BOOOTMGR are present (on FAT/FAT32 you need to change the actual name). Of course IF my guess is correct, the "XP" code invokes NTLDR and has the message "NTLDR is missing" the "Vista" one invokes BOOTMGR and has the message "BOOTMGR is missing", your longhorn code could be invoking BOOTMGR but still have the "NTLDR is missing message", but it may well be any other type of problem. jaclaz [1] though it has to be checked if it is possible to do that on a NTFS volume, very likely both tools can only deal with FAT (16 or 32) volumes, so they would only work if you use a (small) Boot partition (what Microsoft would call System) and bootsect.exe remains the only simple tool to fix the issue

Yay, bugs: If there's something I learned working in IT, it's that things never work as expected. It's an endless cycle of trying to get basics to work right, then there's constant want of new features while the basics still don't work and then there are regressions when either implementing or fixing older flaws...rinse and repeat. Windows...I ran them all from 95 to 10, except ME. Still can't say I have a favorite in 2023. But I've grown to accept the flaws so they don't get to me as much as they used to. Some relatable reading: https://www.bruceb.com/2016/05/personal-computers-are-just-too-hard-to-use-and-it-isnt-your-fault/ https://www.bruceb.com/2019/01/its-not-just-your-computer-everything-is-too-hard-to-use-and-its-not-your-fault/

A person could try older versions of Mono. Since it is opensource, there is a possibility that it could be backported. But it might be a complex undertaking, beyond its value.

Since the Total Commander installer isn't silent at all (though when you follow this you get an automated setup) I've compiled a little NSI following the directions to manual installation described in TC's readme.txt Attached is the script for nullsoft installer made with NIS Edit as an EXAMPLE, but you can change the paths of source folder and use it. Notice that the setup language is set to Spanish (but who cares in an unattended install), but Total Commander language is still set to English. If you don't own a copy of TC, you should remove the "WINCMD.KEY" from the script. tcmd603.zip tcmd603.zip