Leaderboard

New build of basilisk/UXP for XP! Test binary: Win32 https://o.rths.cf/basilisk/basilisk52-g4.1.win32-git-20190126-322d0be58-xpmod.7z Win64 https://o.rths.cf/basilisk/basilisk52-g4.1.win64-git-20190126-322d0be58-xpmod.7z diff: https://o.rths.cf/basilisk/UXP-xp-gitdiff-20181110.7z PM28XP build: Win32 https://o.rths.cf/palemoon/palemoon-28.4.0a1.win32-git-20190126-322d0be58-xpmod.7z Win64 https://o.rths.cf/palemoon/palemoon-28.4.0a1.win64-git-20190126-322d0be58-xpmod.7z Official repo changes since my last build: - Disable IntersectionObserver API because of crashes. (ac1beef5c) - Actually unlink targets from registered intersection observers. (9adcf4429) - Revert "Disable IntersectionObserver API because of crashes." (5ef0018a5) - Properly camelCase dom.intersectionObserver.enabled pref. (9a954e2d1) - Update libwebp to version 1.0.2 (d1a0bfe22) - Make resuming of decoding work for anonymous decoders. (64d65e096) - Make Sourcebuffer::AppendFromInputStream handle canceled image loads. (87bef3e99) - Check for contiguous buffer state. (8dd8df90b) - [BASILISK] Disable WebEx support. (ef75531aa) - Fix bookmarks backup logic. (99f5afe64) - Fix incorrect file reference in `onDownloadDragStart` (322d0be58) My changes since my last build: - enabled --enable-webextensions build option in basilisk/UXP builds

https://abcnews.go.com/WNT/video/air-traffic-controllers-union-workers-breaking-point-60607105 Saw this on the news tonight... looks like the ATCs are still using Windows XP!

New Palemoon 27 Build! * This build is beyond official 27.9.4 build. 32bit https://o.rths.cf/palemoon/palemoon-27.9.1a1.win32-git-20190126-21b0da255-xpmod.7z 32bit SSE https://o.rths.cf/palemoon/palemoon-27.9.1a1.win32-git-20190126-21b0da255-xpmod-sse.7z 32bit noSSE https://o.rths.cf/palemoon/palemoon-27.9.1a1.win32-git-20190126-21b0da255-xpmod-ia32.7z 64bit https://o.rths.cf/palemoon/palemoon-27.9.1a1.win64-git-20190126-21b0da255-xpmod.7z source repo: https://github.com/roytam1/palemoon27 repo changes since my last build: - hack: add --enable-nightly-build switch for defining NIGHTLY_BUILD (050ffd892) - import changes from rmottola/Arctic-Fox: - Bug 1101903 - Part 1: Convert SharedContext::strict to a method. (c419cb895) - Bug 1101903 - Part 2: Allow parsing and emitting strict mode code in smaller than script-sized units. (d00819026) - Bug 1124362 - Allow strict-reserved names to be method names. (6fd24146f) - Bug 1066227 - Part 1: Create a clean way to create lexical bindings at initalizer sites. (2305b65c6) - Bug 1066227 - Part 2: Rename objectLiteral() propertyList() in preparation for classes. (e53b9cf12) - Bug 1066227 - Part 3: Parser support for basic ES6 ClassStatements (Nightly Only). (5ff4cb3b9) - Bug 1066227 - Part 4: Reflect.parse support for ClassStatements (a67bae8a3) - Bug 1066227 - Tests. (ebe27243e) - Bug 1066229 - Part 1: Create a clean way to emit lexical initializers (2d4900e5b) - Bug 1066229 - Part 2: Factor EmitPropertyList() out of EmitObject(). (09b97b557) - Bug 1066229 - Part 3: Create JSOP_INITLOCKEDDPROP, which adds non-configurable non-writable non-enumerable properties. (80d4961b4) - Bug 1066229 - Part 4: Create JSOP_INITHIDDENPROP, which adds non-enumerable properties. (1c79190e4) - Bug 1066229 - Follow up: Enable |let| in ecma_6/Class/ in browser JS reftests. (12a117456) - Bug 1066229 - Tests. (8577d220a) - Bug 1066229 - Tests. (957f4fead) (99ddd8387) - import changes from rmottola/Arctic-Fox: - Bug 1134638: 10. Inline SIMD comparisons in Ion (6bafd7b98) - Bug 1134638: 11. Add type checks in move emitter and LIR generation (a7ae1e2b2) - Bug 1134638: 12. Inline with{X,Y,Z,W} in Ion (abd1dd915) - Bug 1134638: 13. Inline splat in Ion (ca6db67bb) - Bug 1134638: 14. Inline SIMD getters (signMask, .x, .y, .z, .w) in Ion (ea8a76e4f) - Bug 1134638: 15. Inline select/bitselect in Ion (7ebcd4d06) - Bug 1134638: 16. Use more macros (2f5090a52) (21b0da255) My changes since my last build: - enabled --enable-nightly-build and --disable-replace-malloc build options

Windows 10 v22H2 - This Update List has been updated to: June 10th 2025 Download the Media Creation Tool Here for Windows 10 November 2022 Update Please note - I will continue to provide update list beyond the end of support date of Windows 10, and the ESU programme! Win10-v22H2-x64.ulz

Windows 7 SP1 ESU Update Lists are no longer available for download, and this thread can be retired!

ARDC 11.0.23 dropped support for IE versions 8,9 and 10. So even if we could somehow get it running on XP, without IE11 it still wouldn't be full-featured. (note: 10.1.12 also dropped support for XP)

New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rths.cf/boc-uxp/mailnews.win32-20190126-d31e5ac-uxp-322d0be58-xpmod.7z Browser-only Suite Win32 (removed due to request) source patch (excluding UXP): (removed due to request) No Official repo changes since my last build. For UXP changes please see above.

I only mentioned it because @Vistapocalypsesaid in his previous post "Support for Windows XP was dropped beginning with Adobe Reader 11.0.09". It may well have been officially, but it hasn't actually stopped any later versions from working.

@Tangy: You appear to have this setting checked (Prevent WebRTC from leaking local IP addresses) while using New Moon; in all honesty, I don't think it has any bearing on New (Pale) Moon, since WebRTC is disabled there at code level... But it's certainly applicable on FirefoxESR 52.9.0, Serpent 52.9.0 and even Serpent 55.0.0; the wiki link for that feature, for anyone concerned, is: https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-leaking-local-IP-address According to tests I performed on both FirefoxESR 52.9.0 and Serpent 52.9.0, this issue you report appears to manifest itself exclusively with the WebExtension version of UBlock Origin ; if one installs the XUL version of uB0, currently at version 1.16.4.7, then the checkbox remains "clickable" no matter the value of boolean pref "media.peerconnection.enabled"; switch to the WE version of uBO (stable channel currently at version 1.17.4) and one discovers that the WebRTC checkbox has been disabled (and text greyed out ), again irrespective of the state of the "media.peerconnection.enabled" boolean pref... ******************************************************************* A word to those using uB0 WE on Basilisk/Serpent 52.9.0 : 1.17.4 is the final version that can be installed in Basilisk 52 out of the box; 1.17.7b2 of the dev channel was (has now been removed from the GitHub repo) equally the last (beta) version to install (out-of-the-box) in either Basilisk 52 / Serpent 52.9.0; this development has been reported first in the official PM forums, https://forum.palemoon.org/viewtopic.php?f=61&t=21241 which also links to the uB0 support reddit: Mozilla fanbois aside (they're so irritating , aren't they?), it was claimed that "Basilisk was never officially supported", while in the end of the thread the author revealed that he had to increase "strict_min_version" (inside extension's manifest.json) to "55.0", because he started using the Web API requestIdleCallback. So, latest dev version 1.17.7rc2 won't install in Bk52 I've done some research and have discovered at least two discrepancies here: 1. For some inexplicable reason, Firefox versions 52.0.2 and 53.0.3 (release channel) as well as 52.9.0 (ESR channel) do not honour the "strict_min_version": "55.0" requirement and version uB0 1.17.7rc2 has no problem installing and working there... 2. While the MDN documentation states that window.requestIdleCallback() is "Implemented but disabled by default" in Firefox v53-55, I found boolean pref "dom.requestIdleCallback.enabled" extant (but defaulted to false) in all 3 mentioned Firefox versions (52.0.2, 52.9.0, 53.0.3); so, at least in theory, Firefox >=52.0 already meets the new requirement by @gorhill, provided the user manually flips "dom.requestIdleCallback.enabled" to true; what is even more important is the fact Moonchild devs have already defaulted that pref to true in Basilisk 52, so there's no actual reason why the Basilisk browser should be exempt from the list of supported (by latest uB0 WE) browsers - but, sadly, @gorhill does not follow closely Basilisk's development, hence his decision to block it based solely on its reported appVersion string ; also worth noting is that Serpent 55.0.0/moebius doesn't exhibit this issue because, its appVersion string reporting 55.*, it already fulfils the new enhanced requirements... To cut a long story short, I downloaded file uBlock0_1.17.7rc2.firefox.signed.xpi to disk and manually changed line 5 in manifest.json file to read: "strict_min_version": "52.0", ... then the extension had no problem installing and working as expected in Serpent 52.9.0 Of course, when Moonchild's new unfortunate plan (to remove WE support in Bk) bears fruits, this post of mine would be a moot one... *******************************************************************

Tested and working.

Direct links for January 2019 updates: WES09/POSReady 2009 update (English only), IE8 cumulative security update (English), .NET Framework 2.0 SP2 and .NET Framework 4.0 updates (international), Office 2003 SP3 security update http://download.windowsupdate.com/c/msdownload/update/software/secu/2018/12/windowsxp-kb4481275-x86-embedded-enu_5160cf8226e525f266f39e7279ce39e6176cece9.exe http://download.windowsupdate.com/d/msdownload/update/software/secu/2019/01/ie8-windowsxp-kb4480965-x86-embedded-enu_469b647b191dac942734a9a64e05bc27321e79a5.exe http://download.windowsupdate.com/d/csa/csa/secu/2019/01/NDP20SP2-KB4480087-x86_010990466ABCF053D7164DFFE1BC0812B5A86B96.exe http://download.windowsupdate.com/d/msdownload/update/software/secu/2019/01/NDP40-KB4480077-x86_05E61336A238A90796BCDA78D13F0982075F2A2E.exe http://download.microsoft.com/download/0/5/5/055B2A2C-2102-40D1-B0C7-A0BF29DEA79B/office2003-KB4461635-FullFile-ENU.exe P.S. Windows Embedded Standard 2009 (WES09) support has ended. WES registry keys should be removed. There should be only POSReady key left from now on.

How they could drop 1/4 of their users, that's crazy. That company made billionaires and that's how they treat those who made them so rich. I hope they will pay for that someday.

Correct. So we can reasonably expect that Windows 7 will probably continue receiving Chrome updates until at least January 2022 three years from now. This ComputerWorld article addresses just that in addition to other milestones during Windows 7 end of life (EOL): https://www.computerworld.com/article/3322618/microsoft-windows/the-definitive-windows-7-retirement-timeline-countdown.html However, I believe that Windows 7 will persist with high market share for years due to the fact that Windows 10 has much higher system requirements (XD or NX bit execute disable bit processor, etc). In contrast, it was relatively easy to install Windows 7 on a Windows XP computer dating back to the original Pentium 233. Windows 7's market share in January 2022 probably will strongly influence Google's decision either way on whether or not to continue or discontinue support. Infected machines could wreak havoc on the rest of the Internet. Also, don't forget that Chrome 49 (49.0.2623.112 m) is still highly serviceable on Windows XP. I'm still using it nearly three years later! Adobe Flash Player updates for Chrome (PepperFlash) still work if you follow my instructions here: http://sdfox7.com/chromexp3.htm