Leaderboard

New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20260530-40a79c75-uxp-3c23f8ee4e-xpmod.7z BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20260530-40a79c75-uxp-3c23f8ee4e-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/boc-uxp/tree/custom * Notice: the profile prefix (i.e. parent folder names) are also changed since 2020-08-15 build, you may rename their names before using new binaries when updating from builds before 2020-08-15. -- New build of HBL-UXP for XP! Test binary: IceDove-UXP(mail) https://o.rthost.win/hbl-uxp/icedove.win32-20260530-id-656ea98-uxp-3c23f8ee4e-xpmod.7z IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20260530-id-656ea98-ia-c642e3c-uxp-3c23f8ee4e-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/icedove-uxp/tree/winbuild https://github.com/roytam1/iceape-uxp/tree/winbuild

I continued my conversation with Copilote, with following question: "In an earlier conversation today (on another browser) Copilot said Bing was still indexing msfn.org. Was this an error, or is it possible the AI-engine was so called 'hallucinating'?" The answer was interesting (at least to me, probably not to AstroSkipper ). Cited small part of Copilot's answer only: "The earlier answer you saw was not you imagining things — it was almost certainly a case of the AI giving an overconfident but incorrect statement. In other words: yes, that was a hallucination, and I can explain exactly why it happens in this specific situation. 🎯 Short, direct answer Bing used to index MSFN normally, but it no longer indexes new MSFN content reliably. If another Copilot instance told you “Bing is still indexing MSFN,” that was incorrect — a classic AI hallucination caused by outdated assumptions about how search engines behave. (......) Bing is still returning MSFN pages, but it is not indexing new pages beyond ~2025. (....)."

No, we can't! I'm not saying to take my word for it, I would love for somebody to "trick" Cloudflare. But yeah, ALL SIGNS POINT TO *NO*, it can't be done! My city utilities (sewer and trash) is behind Cloudflare. Like CLOCKWORK, any browser older than a mere TWO MONTHS (just under, actually) can *NOT* be used to pay city utilities. So I've been "experimenting" for the last YEAR (at least). You can *NOT* spoof a UA, you can *NOT* fake Client Hints, you can *NOT* polyfill javascript. I've done a "million" things (exaggerating, but you get the idea). I'm not exactly a "stupid person" (how many people do you know that can FAKE CLIENT HINTS). I'm telling you, IT CAN'T BE DONE. I've been on dozens of sites that are smarter than me and they can't do it either. IT CAN'T BE DONE. The "technology" simply does not exist. Cloudflare is GREAT at what they do. I'm going to keep trying to "break" it. But so far, IT CAN'T BE DONE.

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260530-3219d2d-uxp-3c23f8ee4e-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260530-3219d2d-uxp-3c23f8ee4e-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260530-3219d2d-uxp-3c23f8ee4e-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260530-d849524bd-uxp-3c23f8ee4e-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260530-d849524bd-uxp-3c23f8ee4e-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260530-d849524bd-uxp-3c23f8ee4e-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260530-d849524bd-uxp-3c23f8ee4e-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260530-d849524bd-uxp-3c23f8ee4e-w7plus-avx2.7z Official UXP changes picked since my last build: - Re-land: Fix devtools on 32-bit big endian platforms (0915736715) - Issue #3053 - Implement CSSStyleSheet constructor (f5a84f4ad2) - [js] Use size_t when inflating UTF8 (7bbdccd376) - [NSS] Fix instances of softoken attributes freed after owning object. (300dd371b2) - [NSS] Handle SEC_ASN1_NULL in sec_asn1e_contents_length. (9179441f96) - [libjar] Check Jar entry names for nulls. (aadb6beb07) - [NSS] Align PKCS7 digest array with digestAlgorithms. (089170ae83) - [NSS] NSS_CMSContentInfo_SetContent: only modify cinfo if everything succeeds. (7167a8fabc) - [NSS] Initialize src in SEC_PKCS5GetIV (07201fa1ae) - [NSS] Avoid integer overflow when converting AVA value to hex string. (6511833580) - Bug 2029771 - Heap use-after-free in [@ token_destructor] reading tok->pk11slot after nssToken_Destroy frees the token arena. (57bef0265c) - Bug 2029782 - fix 8-byte over-read of AES-192 key buffer in x86 builds without USE_HW_AES. (92b3f6dd67) - [netwerk] nsRequestObserverProxy ref cleanup. (bb2275d400) - [netwerk] Make nsSocketTransport2::mConnectionFlags atomic. (bb85939429) - Bug 2036905: Fix UDPSocketParent::ConnectInternal data race on mSocket. (8d4079866b) - [netwerk] Make socket transport hold a reference to TLSServerConnectionInfo. (349f46bbb2) - Bug 2027381 - improve error handling in SECITEM_DupArray with non-null arena. (b3f801743b) - [NSS] Fix maxSize calculation in NSSUTIL_AddNSSFlagToModuleSpec. (c36357a954) - Revert "Issue #3092 - Perform a minor GC on tab close" (3ae3595f6a) - Revert "Issue #3092 - Initial idle GC implementation" (860d4457ae) - Revert "Issue #3092 - Implement parallel sweeping and compaction tasks" (52ce9ebea5) - Revert "Issue #3092 - Implement BackgroundFinalizeTask for parallel garbage collection finalization" (ac0510f380) - Revert "Issue #3092 - Add new GC sweep tasks." (e95b229db8) - Revert "Issue #3092 - Refactor WASM compilation handling" (d582d12ad8) - Revert "Issue #3092 - Safely parallelize GC background finalization" (c144b4f403) - [NSS] Fix use of uninitialized length after failed PK11_SignWithMechanism/SymKey. (2a26d9508b) - Bug 2029818 - avoid refcount over-release in CERT_CertChainFromCert error path. (62d731d2c2) - [DOM] Check values in audio resampling. (244c614a47) - [layout] Hide accessible carets when needed. (4bf236902c) - [libvorbis] Allocate memory with _ogg_malloc (e9c3451d54) - No issue - Remove ISO-2022-JP from menu, overridability and detector. (c690e26c67) - [gfx/layout] Simplify textruns (b611d80223) - Bug 1784128 - Assert count passed to PR_Read/PR_Write in nsFileStreamBase fits INT32_MAX. (f83e05cf23) - [DOM] Hold a strong ref to VoiceData in nsSynthVoiceRegistry::RemoveVoice. (2f73a3004b) - [media] ffvpx patch: Fix leak in flac decoder in case of alloc failure. (9afa7a80cc) - [DOM] Stop speech synthesis if the originating document is closed. (f041eb0607) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. Update Notice: - You may delete file named icudt*.dat and icu63.dll inside program folder when updating from old releases. * Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

I would recommend updating to version 144, that opens Cloudflare sites OK for me. Incidentally, they are now blocked on 360Chrome too, so I think that's the beginning of the end for any further use of that browser!

AGREED. But remember, not all Cloudflare capcha's are "identical". The one for my city utilites goes into an ENDLESS LOOP for SUPERMIUM v144, Chrome v144, and Chromium v144. But yet that is the "newest" we have for SUPERMIUM. Supermium CAN pass the Cloudflare capcha offered up by BING if I want an AI-generated javascript kick-in-the-right-direction. But it can NOT pass the Cloudflare capcha to pay my city utilities.

Right, I’ve calmed down now and am trying to take a fresh look at the whole situation and assess it. At first, I thought Google was mainly to blame. @NotHereToPlayGames believes that the owner and administrator @xper are solely to blame. The truth probably lies somewhere in between. Here is an alternative perspective on the whole matter from a very special source whom I am inclined to trust. I will not answer any questions about the nature of this source. It enjoys incognito status. So, believe it or not. The cause: The "Japanese Keyword Hack" (or SEO spam injection) The fact that Google search results display Thai characters or Asian text, even though the actual page is in English, is due to a security vulnerability in the forum software that was exploited by automated spam bots. In professional circles, this is usually referred to as the "Japanese/Thai Keyword Hack". 1. What the spammers did Automated bots exploited a vulnerability on MSFN (often via the internal search function, registration pages or by generating thousands of fake profiles/posts). Unnoticed in the background, so to speak "invisible", they generated millions of artificial, low-quality URLs on MSFN, which were crammed with Thai terms, casino links, dubious diet pills or counterfeit branded products. 2. What Google did during the Core Update Google crawled these hidden spam pages. As a Core Update re-evaluates the entire index, the algorithm noticed the sheer volume of this Thai spam content on MSFN. As these generated spam pages were highly optimised for the Google bot, the algorithm mistakenly assumed that the main topic or main language of certain forum sections was now suddenly Thai. In the search results, Google then mixes the page’s actual title with the injected Thai keywords from the cache, which is why the links look so strangely masked to you. 3. The consequence: Classification as a spam farm Because the Google bot suddenly found millions of pieces of Thai spam content on MSFN, the algorithm pulled the emergency brake. Google classifies the domain at this point as "hacked" or "abused for spam". This leads to an automatic, algorithmic (or sometimes manual) block and a massive wave of de-indexing. In doing so, Google protects its users from suspected malware. Summary for clarification There is no malicious intent on Google’s part: Google does not “think” like a human. The bot simply sees: “Suddenly, 80% of all pages on this domain are Thai spam – so the entire domain is corrupted.” It is not the intention of MSFN: The MSFN administration hasn't done much wrong; it has simply fallen victim to an aggressive, automated wave of hacking that exploited a technical vulnerability in the forum software to carry out illegal SEO sinking. In practical terms, this means: Only once the MSFN administration, @xper and @Tripredacus, has completely removed all these fake URLs, profiles and injections from the server, closed the security loophole and sent a clean re-review request to Google via Search Console will the Thai characters disappear and the site slowly recover its position in the index.

And here is another example to demonstrate what Google has done with their index: For years, the ProxHTTPSProxy and HTTPSProxy thread has ranked number 1 in Google for the search term "httpsproxy windows xp", as it still does for Mojeek and Brave only at the moment. Zero results which means Google doesn't even know me anymore and technical knowledge is withheld from users of this search engine. To hell with Google Search! Complete de-indexing, as with everything else. Just an example!

Yes, searching for "msfn.org/board" on Bing also gives me sh*t results... So, Copilot is clearly hallucinating.

It's the best, for now! Finds @D.Draker!

Holland here (with Firefox 151.0.2 on Windows 10 64-bits): Google AI is aware of existence of msfn.org, but give NO links to msfn.org, which is strange. Searching with site:msfn.org "Windows XP": Bing.com gives results with "MSFN" "Windows XP" (NOT with "MSFN Windows XP" - which is a BAD search-phrase anyway): And with site:msfn.org "Windows XP":

I hope you don't mind, but I don't do google. Quite outrageous: startpage.com in latest Serpent 52.9 lists msfn.org as 14th find (on first page) but with unreadable characters, but I remember seeing similar some time ago and the duck lists it on the second page 1st place but with crap characters.

actually how can google index msfn now. DDG is also affected:

I can get msfn results from google if I do a site:msfn.org search, I then get a mixture of correct results and the hacked results. So, there are results there but it's as if the Google crawler has been fed the hacked results. As I still can't find a way to arrive on one of these hacked pages I assume it's Google's own crawler that has been compromised. FWIW, this is https://msfn.org/robots.txt User-agent: * Allow: / Ben.

The resullts with mojeek.com shown to me basically suck, look at them. 1st = absolutely not popular topic made by an obscure member who left ages ago. 2nd = "Hello MSFN! - Introduce Yourself!", Who would be interested in that?!?!? That's it! Conclusion, mojeek is as bad as others, and the resullts look like they can vanish any minute, too. Basically it looks like leftovers from old indexing. Gästebuch (Guestbook) shown in German language, as expected from my location, but it's not relevant and shows 404, mojeek.com gave me plain HTTP link, which again tells it sucks. Sorry for my opinion.

@AstroSkipper, with all my love to you, a bit of explanations regarding Asia. The proper language name is Siamese, as it includes a much broader region, set of countries: NOT only Thailand/Siam itself. It's spoken in Central Thailand and Thai Chinese enclaves throughout the country, Cambodia (Koh Kong), Myanmar (Tanintharyi). Speakers: L2: 44 million (2024), Total: 71 million (2024) Language family: Kam–Tai I guess it's way more than 71 million now! It's a rather huge number, surely could be highly profitable for the spamming, ad purposes.

New build of post-deprecated Serpent/moebius for XP! * Notice: This repo will not be built on regular schedule, and changes are experimental as usual. ** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions. Test binary: Win32 https://o.rthost.win/basilisk/basilisk55-win32-git-20260530-7189d3699-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk55-win64-git-20260530-7189d3699-xpmod.7z repo: https://github.com/roytam1/basilisk55 Repo changes: - Revert "ported from UXP: Issue #3092 - Safely parallelize GC background finalization (e9826f55)" (f1d082056) - Revert "ported from UXP: Issue #3092 - Fix unsafe GC multithreading changes (f0cba412)" (d27f358dc) - Revert "import from UXP: Issue #3092 - Initial idle GC implementation (18ddd00a)" (5e38c6ebd) - Revert "ported from UXP: Issue #3092 - Implement parallel sweeping and compaction tasks for improved garbage collection performance (3433d538)" (b24b0b646) - Revert "ported from UXP: Issue #3092 - Implement BackgroundFinalizeTask for parallel garbage collection finalization (c0677633)" (ea9e25798) - Revert "import from UXP: Issue #3092 - Add new GC sweep tasks. (47746b47)" (2332bc302) - Revert "ported from UXP: Issue #3092 - Refactor WASM compilation handling (a7a75b78)" (6108ea66a) - import from UXP: Re-land: Fix devtools on 32-bit big endian platforms (09157367) (50cedf4ac) - ported from UXP: Issue #3053 - Implement CSSStyleSheet constructor (f5a84f4a) (ddeba088c) - import from UXP: [js] Use size_t when inflating UTF8 (7bbdccd3) (02d728c6c) - import from UXP: [NSS] Fix instances of softoken attributes freed after owning object. (300dd371) (cd4767c93) - import from UXP: [NSS] Handle SEC_ASN1_NULL in sec_asn1e_contents_length. (9179441f) (0ac0961f0) - import from UXP: [libjar] Check Jar entry names for nulls. (aadb6beb) (ccdbe4215) - import from UXP: [NSS] Align PKCS7 digest array with digestAlgorithms. (089170ae) (6725ca403) - import from UXP: [NSS] NSS_CMSContentInfo_SetContent: only modify cinfo if everything succeeds. (7167a8fa) (150f7251c) - import from UXP: [NSS] Initialize src in SEC_PKCS5GetIV (07201fa1) (0cd1f405c) - import from UXP: [NSS] Avoid integer overflow when converting AVA value to hex string. (65118335) (813a4128d) - import from UXP: Bug 2029771 - Heap use-after-free in [@ token_destructor] reading tok->pk11slot after nssToken_Destroy frees the token arena. (57bef026) (160c8de65) - import from UXP: Bug 2029782 - fix 8-byte over-read of AES-192 key buffer in x86 builds without USE_HW_AES. (92b3f6dd) (eae85f288) - import from UXP: [netwerk] nsRequestObserverProxy ref cleanup. (bb2275d4) (13f345626) - import from UXP: [netwerk] Make nsSocketTransport2::mConnectionFlags atomic. (bb859394) (30b1e9927) - import from UXP: Bug 2036905: Fix UDPSocketParent::ConnectInternal data race on mSocket. (8d407986) (ed08f977e) - import from UXP: [netwerk] Make socket transport hold a reference to TLSServerConnectionInfo. (349f46bb) (204c60674) - import from UXP: Bug 2027381 - improve error handling in SECITEM_DupArray with non-null arena. (b3f80174) (4c0ddeea1) - import from UXP: [NSS] Fix maxSize calculation in NSSUTIL_AddNSSFlagToModuleSpec. (c36357a9) (25cfe00f9) - import from UXP: [NSS] Fix use of uninitialized length after failed PK11_SignWithMechanism/SymKey. (2a26d950) (8bc7cd06a) - import from UXP: Bug 2029818 - avoid refcount over-release in CERT_CertChainFromCert error path. (62d731d2) (60c2cf380) - import from UXP: [DOM] Check values in audio resampling. (244c614a) (fc43479c0) - import from UXP: [layout] Hide accessible carets when needed. (4bf23690) (1ceaab06a) - import from UXP: [libvorbis] Allocate memory with _ogg_malloc (e9c3451d) (3c719091d) - import from UXP: No issue - Remove ISO-2022-JP from menu, overridability and detector. (c690e26c) (670720d41) - ported from UXP: [gfx/layout] Simplify textruns (b611d802) (3dc9429a3) - ported from UXP: Bug 1784128 - Assert count passed to PR_Read/PR_Write in nsFileStreamBase fits INT32_MAX. (f83e05cf) (62fdd7306) - import from UXP: [DOM] Hold a strong ref to VoiceData in nsSynthVoiceRegistry::RemoveVoice. (2f73a300) (301814744) - import from UXP: [media] ffvpx patch: Fix leak in flac decoder in case of alloc failure. (9afa7a80) (3e56e3dd7) - import from UXP: [DOM] Stop speech synthesis if the originating document is closed. (f041eb06) (7189d3699)

@Dietmar Yeeeeeeeeeeeaaaaaaaaaaaa! I patched hal.dll to fix reboot WinXP 64-bit booted on UEFI mode 0x106BB: 7F 0F > 74 24 0x106E1: CC CC CC CC CC CC CC CC CC > B0 06 66 BA F9 0C EE EB FE Tested problematic PC's: Gemini Lake (Dell Wyse 5070), Valleyview SoC (Asus J1800I-C). Now WinXP reboot properly under pure UEFI The patch should work on 95% of PCs, especially Intel ones. @Dietmar Please test reboot on yours Dell Wyse and report. Test also my kdcom.dll patch for WinDbg

https://msfn.org/board/topic/186953-supermium/page/151/#comment-1287479 windows offer functions for directorys often they are sniffed together they offer like C:\ - (rootdrive) C:\windir - (aka C:\windows) the others are then sniffed together like C:\windows + \spool = C:\windows\spool %windir%\system32\DllCache = C:\windows\system32\DllCache ExpandEnvironmentStrings is a such core function a other is SHGetSpecialFolderPathA https://learn.microsoft.com/en-us/windows/win32/api/processenv/nf-processenv-expandenvironmentstringsa https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetspecialfolderpatha %ProgramFiles% (probaly like rootdrive (c:\) + (Program Files) = c:\Program Files %ProgramFiles(x86)% for example is not for x86 its a folder for 64 bit OS on 32 bit this function fails %APPDATA% for example is different in XP to win7 but in xp it is C:\Documents and Settings\All Users\Application Data with %ProgramFiles%, %APPDATA%,%SystemDrive%,%ALLUSERSPROFILE% and %windir% - you probaly can make all the folders you need also often this strings are often stored somewhere in the registry

No UA will fix that. crx4chrome may be trying to INSTALL instead of trying to DOWNLOAD and the INSTALL is being blocked (ie, such as would happen if using an UNGOOGLED version). Does v122 have a flag similar to this? ie, the MIME type options would be to DOWNLOAD instead of INSTALL:

<disregard previous statement. e3k is both faster by score *and* faster by duration of test.> <granted, this also compares v144 to v150 because those are the most recent of both forks> <I personally like e3k *way more* than Supermium. BUT... I would also call it more of a "gut feeling" than a "scientific justification".> <Plus, in my readings throughout the 'net, there are DOZENS of forks that REFERENCE e3k as their "base" and *NONE* that reference Supermium as their "base".> Here is my Supermium test result: Here is my e3k test result: