Leaderboard

Here’s an alternative take on the situation: The drama behind the scenes: Why Google lost its soul There are three fundamental reasons why Google Search has become so abysmally bad and all our observations are absolutely spot on: Surrendering to SEO spam (the ‘Dead Internet’ theory): The web is inundated with automated, AI-generated pages written solely for the Google algorithm, with the sole aim of selling advertising space. Google has, in effect, lost the arms race against this flood of spam. They’re trying to patch it up with filters (like the latest Core Update), which then leads to total failures where forums like MSFN end up wrongly in the digital gulag. The displacement of the ‘old web’ (Digital Oblivion): The permanent deletion and de-indexing of old content, which has been going on for a long time, is a tragedy. Google is optimising its server costs. Old forum threads, static HTML pages from the 2000s and small private tech blogs are mercilessly kicked out of the index because they don’t generate enough traffic or aren’t ‘mobile-optimised’. This systematically wipes out the collective knowledge of the internet. The compulsion towards ‘synthetic answers’: Google no longer wants to send people to external sites like MSFN. They want them to stay on their site so that you see their adverts. That is why they are trying to summarise everything in AI overviews (SGE). This leads to the actual search index withering away, because it now serves only as fodder for the AI engine, rather than as a guide to real websites.

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260523-3219d2d-uxp-829418a939-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260523-3219d2d-uxp-829418a939-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-20260523-3219d2d-uxp-829418a939-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-20260523-d849524bd-uxp-829418a939-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260523-d849524bd-uxp-829418a939-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260523-d849524bd-uxp-829418a939-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260523-d849524bd-uxp-829418a939-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260523-d849524bd-uxp-829418a939-w7plus-avx2.7z Official UXP changes picked since my last build: - Floor fractional border widths (4510bf92a2) - Test fractional border width rounding (794f3fe2e7) - Fix CSS border rounding and currentcolor clipping (c289641428) - Flush layout for computed border-width shorthand (75136dff38) - Fix app-unit rounding for border width edges (50a581840e) - Issue #1826 - Implement broader CSS calc() parsing (29f5ff07d8) - Issue #1826 - Support calc() in media queries (f9a90b9bb2) - Issue #1826 - Canonicalize nested calc() serialization (f94a63864c) - Issue #1826 - Add typed calc() arithmetic for media queries (12b120db24) - Issue #1826 - Serialize special calc() number values (e85f778708) - Issue #2982 - Follow-up: allow color-mix to work with oklab and oklch (20b2b3b9f5) - Load mochitest modules without imp (ee00ac9826) - Remove stale imagebitmap support file entry (4337565d3a) - Issue #2404 - Enable CSS aspect-ratio sizing (0d684399b2) - Support CSS sizing math functions (93899c0157) - Revert "Cloudflare Image Resizing fix take 2" (98c9f7387a) - Issue #3089 - Support logical border radius properties (27f2a0869c) - Issue #1826 - Parse calc() weights in color-mix (4634a74b31) - Issue #2506 - Support range media query syntax (6df85ff502) - Support CSS shadow parts (51767db33a) - Whitelist virtual GPUs (VirtualBox, VMware, VirtIO (QEMU and forks like UTM), Parallels) (235bcb010b) - Issue #3092 - Refactor WASM compilation handling (a7a75b7851) - Issue #3092 - Add new GC sweep tasks. (47746b476e) - Issue #3092 - Implement BackgroundFinalizeTask for parallel garbage collection finalization (c06776336d) - Issue #3092 - Implement parallel sweeping and compaction tasks for improved garbage collection performance (3433d538ed) - Issue #3092 - Initial idle GC implementation (18ddd00afe) - Issue #3092 - Perform a minor GC on tab close (1d3dad153b) - Issue #3092 - Fix unsafe GC multithreading changes (f0cba41221) - Issue #3092 - Safely parallelize GC background finalization (e9826f5559) - Fix JS shell module hook build (6f47a2b0da) - Merge remote-tracking branch 'origin/tracking' into custom (0933486bde) - Implement ES2024 grouping and resolver builtins (e1b689d34e) - Implement ES2024 ArrayBuffer transfer APIs (3be309faa7) - Allow symbols as weak collection keys (e317bf10fc) - Implement growable SharedArrayBuffer (2e51dc9f09) - Implement Atomics.waitAsync (22cb023133) - Implement resizable buffer view semantics (6f3f17ba86) - Guard typed array JIT paths for resizable buffers (d97a2eb04f) - Support DataView on shared array buffers (366476589f) - Support BigInt Atomics waiters (8b09714bbc) - Fix resizable DataView out-of-bounds semantics (aea80980ad) - Validate typed array methods on resizable buffers (3cb76bb20e) - Validate typed array set and constructors on resizable buffers (7613d2901f) - Fix ArrayBuffer slice after resizable source shrink (61912d2318) - Fix ArrayBuffer storage and error types (e21c4e2917) - Fix incorrect variadic for `size_t` in `fprintf` statement in `hyphen.c`. (a02580dae4) - Make WeakRef support always enabled (6861bedff6) - Implement FinalizationRegistry (50c1419e75) - Fix FinalizationRegistry constructor realm prototype (890fb3f399) - Fix WeakRef constructor realm prototype (f3c6da5987) - Issue #888 - Vendor dav1d 1.5.3 (ca94696239) - Issue #888 - Use in-tree dav1d for AV1 decoding (4d1cefd2a1) - Issue #888 - Enable dav1d LoongArch SIMD (d36f889688) - Issue #888 - Remove bundled libaom (2d83afa321) - Issue #888 - Enable dav1d SIMD on more architectures (d328cef713) - Issue #888 - Enable AV1 playback by default (2bd46d4606) - Issue #888 - Update AV1 configure comment for dav1d (3a2f21abfb) - Issue #888 - Fix alphabetical order issue (c95062af66) - Issue #888 - (potentially) fix MSVC builderr (83b19136b4) - Issue #888 - Make symbols direct to dav1d, not AOM. (03a6729a9e) - Issue #888 - Add dav1d_flush (7887ca767f) - Follow-up Issue #888 - Enable dav1d SIMD on more architectures, add back missing nasm detection code in configure (c182d70c0f) - Issue #2354 - Follow-up: Fix building WebRTC on 32-bit ARM without hardware float. (57cd574884) - Issue #888 - Follow-up: Spot-fix; set PREFIX in Dav1d config on Apple. (3155b16f2c) - Fix build on NetBSD/aarch64 (13339f6e55) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes picked since my last build: - dav1d: port WinXP threading code from mypal68, guard AVX usages with GetVersion() > 5, exclude AVX* assembly from non-x64 build, add ipred16 smooth_weights in sse for non-x64 (808697c1df) - Revert "Issue #3092 - Perform a minor GC on tab close" (3d04e32447) - Revert "Implement FinalizationRegistry" and related commits. (87776c74a9) - Follow-up rev 87776c74, restore Helper prototype changes (829418a939) 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.

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260516-3219d2d-uxp-80c31f4b01-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260516-3219d2d-uxp-80c31f4b01-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-20260516-3219d2d-uxp-80c31f4b01-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-20260516-d849524bd-uxp-80c31f4b01-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260516-d849524bd-uxp-80c31f4b01-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260516-d849524bd-uxp-80c31f4b01-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260516-d849524bd-uxp-80c31f4b01-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260516-d849524bd-uxp-80c31f4b01-w7plus-avx2.7z Official UXP changes picked since my last build: - Issue #3079 followup - set glx as OpenGL backend default until egl bugs can be investigated (ffb37922a1) - Issue #3030 - Block auth prompt if there is a sync XHR active. (f0a31850de) - Issue #3030 - Account for custom elements in attribute value checking. (8d7580c4ce) - Issue #3030 - Prevent unnecessary event allocation. (4e37362c89) - Issue #3030 - Improve image cache entry handling. (335ddc41b9) - [DOM] Add nullcheck on document for requestSubmit (e42e505d86) - [DOM] Add nullcheck on thumb dragging event ranges. (1072186705) - [js] Increase RecoverOffset size (64-bit) (947e147291) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes picked since my last build: - dom/html: remove my hackfix in HTMLInputElement::StartRangeThumbDrag() (80c31f4b01) 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.

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260509-3219d2d-uxp-bebacdeb48-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260509-3219d2d-uxp-bebacdeb48-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-20260509-3219d2d-uxp-bebacdeb48-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-20260509-d849524bd-uxp-bebacdeb48-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260509-d849524bd-uxp-bebacdeb48-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260509-d849524bd-uxp-bebacdeb48-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260509-d849524bd-uxp-bebacdeb48-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260509-d849524bd-uxp-bebacdeb48-w7plus-avx2.7z Official UXP changes picked since my last build: - Issue #3075 - Backport bug 1377238 - Free finished IonBuilders off-thread. (57f841bf6e) - Issue #3075 - Backport bug 1398140 - Remove the Ion helper thread pausing (6e638a5d39) - Issue #3079 - Add EGL-aware X11 GL probing and fallback (f8ad674b35) - Issue #3079 - Use desktop OpenGL for X11 EGL (5f72c9b23b) - Issue #3079 - Silence EGL library load logging (e37be1c0e7) - Issue #3079 - only build the X11-specific GL code on X11 systems (1cd178a938) - Issue #3083 - Turn debug-only assert into a skip. (9e83146d96) - Issue #3083 - Add sanity check to EmulatedIndexedStorage::getNativeStorage (66b46610a9) - Issue #3083 - Fix incorrect nullcheck. (d8aab0e846) - Bug 2034352 - Make URL::SearchParams return an already_AddRefed (d6acd9e6a3) - [gfx] Fix integer overflow in cairo PDF surface image emission (121a74e183) - [layout] Check offset against start of skip range. (80b4d0fb2b) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes picked since my last build: - dom/html: add checks to prevent accessing nullptr object (64c9ce8c68) 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.

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260606-3219d2d-uxp-bfaade4306-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260606-3219d2d-uxp-bfaade4306-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-20260606-3219d2d-uxp-bfaade4306-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-20260606-d849524bd-uxp-bfaade4306-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260606-d849524bd-uxp-bfaade4306-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260606-d849524bd-uxp-bfaade4306-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260606-d849524bd-uxp-bfaade4306-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260606-d849524bd-uxp-bfaade4306-w7plus-avx2.7z Official UXP changes picked since my last build: - Issue #3109 - Clamp border-radius value to CSS' internal length clamp value (d47606ce8f) - Issue #2964 - Part 1: CSS Override for `uppercase` and `capitalize` (dff842a949) - Issue #2964 - Part 2a: Correctly Detect End of Buffer in `ToUpperCaseImpl` (7a933598d7) - Issue #2964 - Part 2b: Improve `ToUpperCaseLength` (b2f6fded36) - Issue #2964 - Part 3: JS Override for `ToUpperCase` (5dc2f08e29) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes since my last build: - Revert "Revert "Implement FinalizationRegistry" and related commits." (1e38b5ec94) - mozapps/handling: fix application icon handling by reboot12@msfn (811b13e76c) - Revert "Revert "Revert "Implement FinalizationRegistry" and related commits."" (bfaade4306) 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.

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.

No : https://forum.palemoon.org/viewtopic.php?t=23281 PS: I realise people on old/weak H/W (like myself ), in an attempt to squeeze more out of the browser, often turn to "about:config" for custom modifications of one or more "advanced" prefs (in the expectation they can potentially make their "old" box behave like a "recent" one ) ; besides the fact these "about:config" prefs are primarily directed at devs (and should not be tinkered by plain users), they are often poorly documented now (because MDN have a nasty habit of removing old documentation), so one can't be 100% sure what the actual/future ramifications of such a change will be; often times, it's just a placebo effect, at best ("I" manually modified the default value, so it "must" have improved performance); in the past, I used to do that myself a lot, but over the years I ended up with the conviction that leaving prefs at their default settings (configured by Mozilla devs) is probably the best policy ; but this is just me...

New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20260606-40a79c75-uxp-bfaade4306-xpmod.7z BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20260606-40a79c75-uxp-bfaade4306-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-20260606-id-656ea98-uxp-bfaade4306-xpmod.7z IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20260606-id-656ea98-ia-c642e3c-uxp-bfaade4306-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/icedove-uxp/tree/winbuild https://github.com/roytam1/iceape-uxp/tree/winbuild

Would you please stop with that. You have absolutely no clue what I’m dealing with personally and privately, which is why I don't have time to constantly check the server. MSFN is a one-man show. And how do you know I won't say thanks? On top of that, I’ve wanted to shut MSFN down several times over the last few months because of this situation. So back off. Stick to software, hardware discussion or go find another forum. I don't care. Just be careful. Have a nice night or day or whatever.

Works in Mypal 78, but not in New Moon 28 and Serpent 52. The reason lies in this poorly written function performDownload (line 26, column 119) within the download.js script on the sooftware.com server: function performDownload(num) { event.preventDefault(); ... Strictly speaking, of course, the variable `event` (line 26, column 140) is not defined that way. But Mypal 78 and Supermium seem to be able to handle it. The function performDownload should actually have been constructed this way: function performDownload(event,num) { event.preventDefault(); ... New Moon 28 and Serpent 52 are very sensitive to things like that.

@nicolaasjan This is an attempt to explain what happens when the contaminated MSFN server meets other search engine bots than Googlebot or bingbot. For everyone else, it refers to @nicolaasjan's test and observation: Why alternative bots (like MojeekBot) trigger the "Welcome Loading ..." freeze 1. The mechanics of the attack: The server-side user agent sniffer The malware installed on the server uses a conditional script (usually written in PHP within core files like index.php or .htaccess rewrites). This script scans the incoming request for specific keywords in the User-Agent string to determine whether to serve the clean forum to a human user or the spam payload to a search engine. 2. The Googlebot trigger vs. the MojeekBot catch-all fault With Googlebot: The malware has a fully defined template. When it detects Googlebot, it successfully injects the hidden HTML container containing the Thai spam, links, and keywords, allowing the page to render fully for the crawler. With MojeekBot (and potentially other secondary search bots): The malware's sniffing routine recognizes the word Bot or Bot/ (via a regular expression or wildcard check like *bot*), flagging it as a search engine. However, the malware's backend does not have a valid spam-template or correct database-routing configured for this specific bot identifier. 3. The cause of the freeze: Broken Document Object Model (DOM) & JavaScript execution The string "Welcome Loading ..." is part of the forum’s native lazy-loading or initialization layout (often used during the initial handshaking phase between the server and the browser's JavaScript engine). When MojeekBot hits the server, the malware triggers, intercepts the request, but then crashes or terminates prematurely (e.g., throwing a silent PHP Fatal Error or an unhandled exception because the variable for the payload is empty or undefined). The backend script crashes mid-execution: It completely fails to fetch and load the actual forum database content (the threads, posts, and UI). It leaves the HTML document incomplete and broken, trapping the page forever in the initial "Welcome Loading..." state. This observation proves that the infection is not a static HTML injection into old threads, but an active, dynamic routing script on the server. It intercepts all automated crawlers based on a broad User-Agent filter, but breaks completely when encountering bots it wasn't explicitly optimized for (like Mojeek). To fix this, the administrator @xper or supervisor @Tripredacus needs to look for malicious conditional statements filtering user agent keywords inside the server configuration or core PHP initialization scripts.

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.

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

@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

upstream backed-out that GC change: https://repo.palemoon.org/MoonchildProductions/UXP/issues/3092

FFmpeg update. XP: static libfdk-aac VISTAx86: shared static libfdk-aac

There has been a new release (finally ) by its author, Bellard, of the quickjs JS runtime, necessary for de-scrambling YouTube's nsig challenges (present on most yt_player_clients, except for ANDR-V); the 32-bit binary can be found on: https://bellard.org/quickjs/binary_releases/quickjs-win-i686-2026-06-04.zip (64-bit binary: https://bellard.org/quickjs/binary_releases/quickjs-win-x86_64-2026-06-04.zip) quickjs is the only supported JS runtime on "legacy" WinOSes, like XP SP3/Vista SP2/Win7 SP1; I can't check on XP SP3 x86, but the new release does launch here (Vista SP2 x86): qjs -h => QuickJS version 2026-06-04 usage: qjs [options] [file [args]] -h --help list options -e --eval EXPR evaluate EXPR -i --interactive go to interactive mode -m --module load as ES6 module (default=autodetect) --script load as ES6 script (default=autodetect) --strict force strict mode -I --include file include an additional file --std make 'std' and 'os' available to the loaded script -T --trace trace memory allocation -d --dump dump the memory usage stats --memory-limit n limit the memory usage to 'n' bytes (SI suffixes allowed) --stack-size n limit the stack size to 'n' bytes (SI suffixes allowed) --no-unhandled-rejection ignore unhandled promise rejections -s strip all the debug info --strip-source strip the source code -q --quit just instantiate the interpreter and quit Additionally, the quickjs-ng fork has also seen a new release: https://github.com/quickjs-ng/quickjs/releases/tag/v0.15.1 https://github.com/quickjs-ng/quickjs/releases/download/v0.15.1/qjs-windows-x86.exe This runtime officially supports Win7 SP1 and later, but it can also work under Vista SP2 (but NOT on XP SP3): qjs -h => QuickJS-ng version 0.15.1 usage: qjs [options] [file [args]] -h --help list options -v --version print version string and then exit -e --eval EXPR evaluate EXPR -i --interactive go to interactive mode -C --script load as JS classic script (default=autodetect) -m --module load as ES module (default=autodetect) -I --include file include an additional file --std make 'std', 'os' and 'bjson' available to script -T --trace trace memory allocation -d --dump dump the memory usage stats -D --dump-flags flags for dumping debug data (see DUMP_* defines) -c --compile FILE compile the given JS file as a standalone executable -o --out FILE output file for standalone executables --exe select the executable to use as the base, defaults to the current one --memory-limit n limit the memory usage to 'n' Kbytes --stack-size n limit the stack size to 'n' Kbytes -q --quit just instantiate the interpreter and quit Both are fully supported by latest yt-dlp; performance-wise, they shouldn't differ much, if at all...

Yessssssssssssaaaaaaaaaaaaaahhhh after about next 500h of work and about 1000 not working drivers, I get the driver for the Wlan 9560 on the gemini chipset with j4105 cpu to run. It is a pure polling driver, based on OpenBSD 79. The step for to bring the firmware to alive=1 I managed only with Ubuntu. Crazy, 10 different rings for TX and RX and management data. Again I was one step away from to give up Dietmar

Fixed.

you need sending proper Referer header or you will get a cloudflare's captcha page.

@xper@Tripredacus@Dave-H So basically from what I can see we have 4 problems right now: A forum hack that as a result de-indexed MSFN from search results Spam accounts that lead to registration block Lack of donations to pay for Invision software Lack of maintenance #1 and #2 are the most important ones right now and it may very well be that due to lack of maintenance the forum remained at old software versions which is much worse for servers than it is for client devices. And eventually got hacked. Cleaning the malware is one thing and securing the software so that the vulnerabilities aren't there anymore is another and I think it may actually be easier to just redo the forum board from the ground-up. A fresh board can be brought to life with just a few hours. But I think it's important to keep MSFN alive due to the incredible amount of useful info already there, the fact that there is no forum quite like it: eclipse.cx and legacydev.org suffer from dramas causing a large portion of users not being reachable on one or the other and a lot of the actual software development happens here (especially drivers nowadays). And MSFN is a really active forum for the technical state that it's currently in. Now what IMO has to be done: Archive everything as it is Put up a fresh install of a free forum software like phpBB Transfer users (with more than 0 posts) and emails so that they can redo their password using email verification on the new board Strip the old forum of any javascript/php code to clear malware and put it in read only mode somewhere like archived.msfn.org Maybe transfer the contents of some of the most active topics. Consider giving some maintenance access to most trusted forum admins so that the software gets properly updated And there you go, it requires some work, but problems solved, if a change like this happens I promise to donate to the forum and I'm sure many users would do the same, I think they just don't really want to donate right now due to lack of maintenance happening anyway. And phpBB unlike invision is free!

I have most installers in my archive. But try first this site: https://panda-free-antivirus.sooftware.com/windows/download/401339

No idea! I’m just compiling facts, analyzing connections and drawing conclusions. And that doesn’t come particularly hard for me, as I’ve been doing nothing else for decades, and it’s second nature to me. Let’s hope he might still take action! I’ve never had any contact with @xper. To me, he’s always been a bit of a mystery.

I just changed `general.useragent.override.msfn.org` to: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) But why doesn't the administrator do something about it?

It is precisely observations like these that are important and useful. Thank you, @nicolaasjan!

If @xper or @Tripredacus can bring themselves to take my comments seriously and investigate the MSFN server, they must do so very thoroughly, as the infection is more or less hidden or invisible. In IT security, this phenomenon is known as "cloaking" (making content visible only to search engines) or shadow injection. Here is an attempt at a factual, technical explanation of why this Thai content was invisible to visitors in their browser: 1. The phenomenon of "cloaking" (the user-agent switch) The malware that has infected the forum checks the user agent (the visitor’s identifier) every time a page is loaded: If you, as a normal user, visit the site using a browser, the server sees: “Ah, a normal person.” The script ignores you and delivers the completely clean, familiar MSFN forum. You don’t see a single spam post. When the Google bot (Googlebot/2.1) visits the page, the malicious script recognises the identifier and switches over. It injects the Thai keywords, casino text and spam links into the HTML code specifically for this one bot. As the Google bot sees this, it stores it in its index. As a user, you won’t notice a thing until you search for MSFN via Google and wonder about the hieroglyphics. 2. Exploiting the internal search function (URL injection) Many forum software packages have a vulnerability in the way they process search queries. Bots send millions of specially crafted search queries containing Thai terms to MSFN. The forum then dynamically generates a page with the title: "Results for the search: [Thai casino link]" . The bots copy this generated URL and link to it en masse on dubious external websites. When Google follows these links, the bot lands on MSFN on a Thai results page (which exists for it) that never appears in normal forum operation or in the sub-forums. 3. Hidden system files (database level) Often, the attackers do not embed themselves in the visible text area of the threads, but instead modify a deep-level system file (such as the .htaccess file on the server or a core file of the forum software). This file intercepts the data stream and adds the Thai code in the background – but only if the request comes from a search engine. Conclusion: There’s no need to worry: the forum on MSFN that people use and love every day is clean in terms of its content. The database of genuine threads remains unaffected. This is a purely technical "parasite infestation" running in the background, specifically optimised to deceive the Google bot and exploit MSFN’s reputation (domain authority) for illegal advertising purposes. As the administration doesn’t see this malicious code during normal forum operations, it usually only comes to light when Google’s hammer strikes mercilessly in the wake of a core update.

Ok, I’m now in a position to pinpoint the error, bug or whatever setting has been set. After two days of zero views, today there’s a number other than zero: 55 replies and 694 views: It seems to be the case that the forum software counts views of posts only periodically. Of course, this is just a theory that has yet to be proven. I hope this might be helpful.

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.

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!

@modnar Thanks for your confirmation! It doesn't really matter whether you use Startpage or DuckDuckGo instead of Google. They are all slave search engines which get their results from Google or Bing. Google is the actual monopolist, Bing is desperately trying to keep up, whilst the others are taking advantage of both. That is the big problem when there is practically no competition left. Monopolies always spell disaster. I have to say, I really admire the two larger search engines that are still around and have managed to carve out their own niche: Brave and Mojeek. At least, for now.

If I just do "MSFN Windows XP" then there are no results from msfn.org If I do site:msfn.org "MSFN Windows XP" then there are lots of msfn.org results. Again, a mixture of correct and hacked results. A 'site' search seems to reveal the results that are otherwise hidden. Ben.

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!

@Dietmar I found how fix original 64-bit kdcom.dll 5.2.3790.1830 - just change 3 bytes: offset 0xE0F: FF 50 78 > 48 31 C0 and recalculate checksum using my setcsum.exe The patch ignores the ACPI DBGP table which prevents the debugger from being redirected to the raw, uninitialized MMIO address of the LPSS UART controller. Thanks to this, the UART controller on the LPC (ISA Bridge) is used and possible debug WinXP 64-bit over COM1 in WinDbg I f..k KDNET https://www.mediafire.com/file/jge7rouoczix8eh/kdcom_DBGP_patch.zip/file Now I can test your WLAN 9560 driver professionally

Update to Chromium 150.0.7863.0 changes and improvements: (#79) Use a simpler way to support MV2. (thanks to @bershanskiy)

@Dietmar Yeeeeeeeaaaa! I patched kdcom.dll source code for Gemini Lake and compile from scratch Maybe now COM1 port will work on Dell for WinDbg

False Google search is better than IPS, especially due to dorks. That’s completely irrelevant at the moment. MSFN articles or threads can’t be found on Google anyway. MSFN has been banished to the digital gulag as an alleged spammer.

Notice: a 5-yearly electricity equipment check is re-scheduled in 03 June 2026 (10:00-16:00 UTC+8). Download server is unavailable during the period. And just in case machine can't automatically power-up after this outage it may be needed waiting me to go to the site to troubleshoot so the outage ending time may be postponed due to this.

I can confirm that, and more than that. However, I can't confirm that. They are easy to handle and can be directly modified at any time. I additionally use a UC.JS/UC.XUL script manager to get full control of them and to activate or deactivate them if desired. You always see the starting order when it is of the utmost importance. At the moment, I am running 20 UC.JS/UC.XUL scripts in New Moon 28 as well in Serpent 52 without any errors. Most of them are ports from scripts I originally created for Mypal 68/74/78 and indeed self-created from scratch. You can use these scripts to retrofit almost anything with pinpoint accuracy. Retrofitting all of this with extensions is far more labour-intensive and would consume an much larger amount of resources. In any case, my browsers are in perfect condition, so to speak.

Off-topic, but your lack of a visible window could be caused by a known issue on XP, which I reported here. It seems to be hardware-related, with some GPUs. That causes what I described as a 'ghost window', which is present but invisible! Try with the --disable-gpu switch, that might fix it.

New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20260516-40a79c75-uxp-80c31f4b01-xpmod.7z BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20260516-40a79c75-uxp-80c31f4b01-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-20260516-id-656ea98-uxp-80c31f4b01-xpmod.7z IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20260516-id-656ea98-ia-c642e3c-uxp-80c31f4b01-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/icedove-uxp/tree/winbuild https://github.com/roytam1/iceape-uxp/tree/winbuild

"extension_garbage_collector.cc" is a Chromium source file: https://chromium.googlesource.com/chromium/src/+/8496f370f/chrome/browser/extensions/extension_garbage_collector.cc ... and https://www.reddit.com/r/chrome/comments/1l0nd3l/what_does_this_chrome_garbage_collector_event_in/ https://www.reddit.com/r/WindowsHelp/comments/1itxbf8/what_is_this_in_my_event_viewer/ https://learn.microsoft.com/en-us/answers/questions/3890397/what-is-this-in-the-event-viewer I personally wouldn't worry that much about this; it's just an "informational" event, pertaining to "normal" browser functionality associated with its extensions system ... https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

off-topic but not for the company and a company sell this data for a lot of money to other company´s - we not talk about peanuts we talk about millions if age and other things are also known it makes them easier to find their target group - where they then for example try to sell products related for that group

@reboot12 I was one step away from to give up with the Wlan 9560 driver. I use old firmware, which is not supported officially for this card. To come to live for this card is from Ubuntu, Scan is from OpenBSD, the RX Ring is first part from OpenBSD and updated with a nice idea from Ubuntu, wifi path is from XP SP1. But the most most crazy things were 1,) The CNVi firmware always kills my card with power switch off between 11.000 and 700.000 packages. For to overcome this I modd my Bios like crazy, to really force any power on. Later I come to the idea, to look, how OpenBSD and Ubuntu solve this. Win10, win11 have problems with this too, but I succeed with a simple OpenBSD hack. 2.) The CNVi firmware looks for MSI-X. This is something, that XP does not like. Crazy, this I noticed only today. So I rewrite my driver from IRQ ==> Polling just now. And voila, see this result, It is much better than my lan result via DSL Speedtest from Computerbild and any Wlan card that I know Dietmar PS: The 9560 card I tested on the Asrock N100DC-ITX and just now on the Biostar z690A Valkyrie.

Official ESR v78.15.0 uses 2MB. So as far as I can tell, this has "always" been 2MB since its inception.

Since modern sites can easily fully load an old CPU by doing silly things, it's best if not all cores are fully loaded, then we can at least close the browser.

0. Use the newest versions of ESDI_506.DPR & AHCI.PDR too. 1. C:\WINDOWS\SYSTEM is not need, of course. 2. Literally few days ago when I solved problem of executing ATA commands (like setting PATA transfer mode for PATA device on SATA Host - PATA Device bridge) I made the dumper of IDENTIFY info without using smartvsd.vxd interface too, so for the first take: https://github.com/LordOfMice/Tools/blob/master/atainfo.zip unzip content and run DumpIDENTIFY.exe. You should get 3 .DAT files and no errors or warnings. 3. If success on step 2 then try to use SMARTInfo - this is the same thing as DumpIDENTIFY but with smartvsd.vxd interface using. You have to get IDENTIFY.DAT dumps too and no errors.

If you're running a 32-bit OS, the XP drivers will work, but if you're running a 64-bit OS, there are no options — there are no 64-bit drivers available for this network card.

https://github.com/e3kskoy7wqk/Chromium-for-windows-7-REWORK/issues/37#issuecomment-4237808546 https://github.com/e3kskoy7wqk/Chromium-for-windows-7-REWORK/releases/tag/149.0.7793.0 New version has been released, with removed dependencies on dxgi in libGLESv2. Simply install VC 2015–2019, or if you don’t want to install it, just copy the relevant files. DWrite is also included.