VistaLover

... Actually, at the time of this writing, DIRECT links from Adobe STILL work, if you know beforehand the correct filename for the .ZIP file: https://fpdownload.macromedia.com/pub/flashplayer/installers/archive/fp_32.0.0.371_archive.zip Surely, that won't last for long...

... Well, that was quick of them : five whole months before actual deprecation... Perhaps that expedited removal was a knee-jerk reaction on their part, caused by recently increased batch-downloading traffic on the hosting CDN: https://forum.palemoon.org/viewtopic.php?p=193860#p193860 https://web.archive.org/web/20200630185339/https://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html ... however, expect these web archive snapshots to be hunted down by Adobe, as they do not allow redistribution of their closed-source material...

... Does also work in Serpent 52.9.0/Serpent 55.0.0 ; should also work in FirefoxESR 52.9.x, though haven't checked there, TBH...

You are welcome, but I'm not young myself... Each new day for me probably means many thousands of brain neurons dead, never to be replaced again (because, if you didn't know already, brain cells are the ONLY type of human cells that don't multiply/regenerate, only the number of connections between them can grow,,,). That is precisely the case ; SSL Labs / Server Test https://www.ssllabs.com/ssltest/analyze.html?d=winhelp2002.mvps.org caps this site as B, because it only uses TLS_ECDHE_RSA_WITH_AES cipher suites, now deemed weak: (... while, at the same time, still supporting TLS 1.0/1.1). Stay safe/healthy caro amico, the second wave of the Covid-19 pandemic has started in the Balkans/Southern Europe (with Greece, luckily, still at 30-40 daily cases of infection) ...

@roytam1 : Website issue/ bug report in latest New Moon 28 offering : Unfortunately, during the latest days, imgur.com have permanently thrust upon us their new, uglier, resource-heavier, mobile-device-targeting, interface, especially while being in their Upload section: After a successful image upload, you are presented with something like: When you click the Get share links button (to get access to "forum-type" link), a Share Options popup successfully emerges: The Copy Link green buttons do work, however, once finished, you can't dismiss the Share Options popup, because the X sign on the top right of it is unresponsive Actually, to get rid of that popup, you have to click on a page point outside of the popup but below its top, which, to say the least, is non-intuitive... <rant>Grrr... modern page layouts, designed for youngsters on smart phones with touch screens... Good ol' desktop computers are dying a horrible death these days... </rant>

... For fear that my heavily modified, old, NM28 profile would interfere, I started from scratch by downloading a fresh copy of latest NM28 32-bit (buildID 20200724223135) and a new, pristine, profile was created, on which I only imported a previous sessionstore.js file. Once launched, 1. I only installed (from GitHub) uBlock0_1.16.4.24.firefox-legacy.xpi 2. The MVPS filter list isn't enabled by default ; I selected it in the dashboard and applied changes; all went along as expected 3. I clicked the "clock" button at the end of the list entry, as expected the orange triangle sign took its place: 4. I pushed the Update Now button in the top of the tab, the list updated OK: 5. As you asked, I then deselected the MVPS list and applied changes 6. NM28 was restarted; once relaunched, I enabled anew aforementioned list 7. Clicking the Update Now button works as expected for said list here : Here are the loaded/updated contents of the list (inside uB0 itself): ... and, as said already, here is the secure connection result to the filter list itself, via browser: It is my understanding that uB0-legacy uses NM28's libraries to perform connections to HTTPS URIs, so me being on Vista SP2 vs you being on XP SP3 shouldn't really matter (?) ... Possibly something configured in your highly secured setup blocks the needed connection(s) for the list to update itself

... Both secure URIs load fine here under New Moon 28: https://winhelp2002.mvps.org/hosts.txt https://winhelp2002.mvps.org/ ... and the list can be properly (manually) updated in the third-party filters tab of the dashboard:

The last WidevineCDM version that was Vista SP2 compatible was 4_10_1196_0 ; that version was deprecated by Widevine licence servers last August 2019; newer versions, like the currently sanctioned 4_10_1440_18, 4_10_1582_1, 4_10_1582_2 & 4_10_1610_0, have been compiled and optimised by Google (the owners of WV) to target Win7+ Up until Aug 13th 2019, I was able to use the Spotify Web Player in 360 Extreme Explorer v12, until v4_10_1196_0 could no longer acquire decryption licences... The newer Widevine DLLs have a missing function in my Vista SP2 32-bit: If the Extended Kernel satisfies that missing function, then web services requiring the WV CDM should be usable in a Chrome-type browser, which comes with bundled patented decoders; Firefox, for the reasons I outlined earlier, won't be a choice... FWIW, all this ExtdKernel talk here is wayyyy beyond my level of expertise and, since I'm on 32-bit Home Premium install, will remain for me just a reading topic of high interest... (hopefully, in the not so distant future, a pre-compiled "installer"/"package" will be made available for simple Vista lovers, although I understand the redistribution limitations that'll come with such an endeavour...) Best wishes!

Vista SP2's WMF patented decoders (h264/aac), which are installed via the Platform Update Supplement (PUS, KB2117917), have filenames (H.264 decoder is in mfh264dec.dll, the AAC decoder is in mfheaacdec.dll) different to the respective patented decoders already present in Win7 OEM; starting from Firefox 53.0a1, the Mozilla devs have completely removed any support for Vista's WMF decoders, so while e.g. Firefox Quantum 68 may launch under Vista SP2 64-bit with this Extended Kernel (which simply satisfies kernel functions missing in vanilla Vista SP2), it is not instructed in code to search for mfh264dec.dll / mfheaacdec.dll; it does try to locate decoders present in Win7+ (since it properly targets those OSes), but, of course, fails... The only way to tackle this serious shortcoming is if you recompile from source, having first reverted those changesets responsible for disabling Vista's WMF decoders... Related Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1324183 (and my relevant comment https://bugzilla.mozilla.org/show_bug.cgi?id=1324183#c15 which, needless to say, caused a stir with those damn developers...)

When I navigate to https://www.azul.com/downloads/zulu-community/?version=java-8-lts&os=windows&architecture=x86-32-bit&package=jre (filters selected were Java Version: Java 8 (LTS) Operating System: Windows Architecture: x86 32-bit Java Package: JRE), I am informed that the minimum system requirements are Windows (Server) 2008R2; are you implying one can install and successfully use that package (zulu8.46.0.19-ca-jre8.0.252-win_i686.msi) in XP/Vista 32-bit?

This is to be expected and already reported elsewhere: Nothing can be done about that, unless recent ECMAScript 6 javascript features are backported to NM27...

I can confirm: => Works as expected, though, in "classic" style...

... That's good to know... I have not ever been myself a user of ABL or other members of the AB family of content blockers, last thing I remember reading was how much more resource-greedy they were compared to uB0 (and RAM/CPU consumption should always be a consideration on those old hardware setups where NM27-sse is being deployed...). Resources-usage aside, the crux of the matter here is the following question: Does current ABL address successfully the very issues/reasons that forced uB0 to drop PM27 support? As detailed in the previously linked GitHub PR comment, uB0-legacy now needs ES6 support in the browser itself to tackle the removal of certain classes of unwanted content ; does ABL handle such content in a different way? If not, then existing users of uB0-legacy 1.16.4.21 in NM27 should probably stay put at that version (sadly no longer updating ) and face some random/occasional breakage in their ad-removal... It'd be like Chrome 49 users on XP/Vista, who are now confined in using uB0 v1.16.18 for good... Unless something new crops up?

... which, sadly, removes support for Pale Moon 27 based forks, like @roytam1's New Moon 27.x.x (whose sse builds are very popular with our members running pre-SSE2 CPUs): https://github.com/gorhill/uBlock-for-firefox-legacy/pull/239#issuecomment-651090892 https://github.com/gorhill/uBlock-for-firefox-legacy/blob/3524cbc34b30d9555eb7e9089aa4a5ea91465741/platform/firefox/install.rdf#L47-L54 https://github.com/gorhill/uBlock-for-firefox-legacy/commit/990daae

Bk52 (the browser, as test application) was initially built by upstream on top of a fork of the Mozilla ESR 52.6.0 platform code; the derived platform is named UXP. Since then, both the original official Basilisk 52.9.x upstream project as well as roytam1's Serpent 52.9.0 fork have significantly diverged from that starting point, but have also diverged significantly between each other, too... IMHO, stating that Serpent 52 is "based on FF52 code" is no longer descriptive of the current situation... Bk55 (the browser, as test application) was initially built by upstream (Moonchild Productions) on top of a forked Mozilla Nightly 53.0a1 snapshot platform code, with very few 54.x and 55.x code elements merged in; the platform that was produced was named Moebius; the app (browser) built on top of it was named Basilisk and was given an app version of 55.x.x, for (if you ask me) sensationalistic reasons ; much of the initial Moebius code, hence, can be described as a pre-53 Firefox snapshot... Serpent 55 by roytam1 was forked off Bk55/Moebius; that upstream project was abandoned in favour of UXP (and Bk52/UXP); since then, St55 is being infrequently maintained as a code melting pot, merging bits of various other upstream projects (e.g. UXP, tenfourfox, Mozilla and even code from IceWeasel 53.x). TL;DR: Current Serpent 55.0.0 has extremely limited affiliation, codewise, with stable Firefox 55.0

... Being slightly pedantic, but the URL query parameter should be: disable_polymer=1 Be that as it may, the query no longer works for the main YT homepage, https://www.youtube.com/?disable_polymer=1 (classic style is not restored), but still works for independent video URIs: https://www.youtube.com/watch?v=W-z7hoEWaH4&disable_polymer=1 A Google-bot SSUAO however does, as of this writing, work in both cases... [I'm using just "Googlebot/2.1 (+http://www.googlebot.com/bot.html)"]

... But he has already stated that:

... For spell checking in 360EE v12, I'm using the following Chrome Web Store (CWS) extension: Grammar and Spell Checker - LanguageTool ... currently at version 3.1.6 - works quite well, albeit with a bit of fine tuning; I'm only enabling it when inputting text, like in this case... (Like all extensions from CWS when installed on the patched version of 360EE v12, they are not checked automatically against CWS for newer releases, one has to do that manually, say, once weekly, and install the updated version also manually; NB: if you first uninstall the old version (in order to then proceed with the upgrade), all custom settings of the extension will be removed - better first back up the settings, where available...)

... New Moon 28 DOES NOT support WebRTC and the same stands true for (upstream) official Pale Moon 28/29; this has been a long-standing decision made by the Moonchild team, I think after a user poll; main considerations are security and performance toll on the browser... The team currently spends very little time on the WebRTC part of the (UXP) platform code, which is mainly still present (inherited initially from Mozilla ESR 52.6.0 platform) for the sake of Basilisk 52.9.x ... In theory, you could build yourself a custom build of New Moon 28/UXP with the --enable-webrtc config flag, but if you are a social media sites fan (where WebRTC is mostly used), then opt to use for that purpose Serpent 55.0.0/Serpent 52.9.0, where WebRTC is built and enabled by default... Or switch to another browser (are you on XP?) with WebRTC support (probably all Chromium derivatives and, though I don't use it myself on my Vista laptop, MyPal 28.9.3) ... Personally, I avoid ALL social sites like the plague (for security/privacy/performance issues, etc.), so I have currently no need for WebRTC and the like; pretty happy then with NM28 not supporting it... However, I am a democratic person by conviction and respect the right of other people wanting something I consider a nuisance...

Upstream issue #1570 has been closed via commit e5dd97f ; when @roytam1 merges this, the issue should be resolved in next weekend's UXP builds; the issue has been caused by reddit opting to use the latest (ES2020/2021) javascript bells and whistles , breaking in essence all "legacy" browsers... If, like me, you hate infinite scrolling (which is more suited to mobile devices with touch screens) and prefer the previous ("old") reddit layout - much more lenient on resources - then, as suggested by @Montana Slim , you can use (auto-)redirection to "old.reddit.com", which is made very easy via userscripts like Old Reddit Redirect ; for New Moon 28/Serpent 52.9.0, you'd need Greasemonkey for Pale Moon v3.31.4 Should you also want to revert to the previous reddit favicon, then userscripts to that purpose also exist, e.g. // ==UserScript== // @name Old Reddit Favicon // @include https://old.reddit.com/* // @grant none // ==/UserScript== (function () { var link = document.querySelector('link[rel*=\'icon\']') || document.createElement('link'); link.type = 'image/x-icon'; link.rel = 'shortcut icon'; link.href = 'https://i.imgur.com/veJX9o5.png'; document.getElementsByTagName('head') [0].appendChild(link); }) (); (... harvested from https://old.reddit.com/r/Enhancement/comments/7jd9a7/any_reason_for_new_favicon_it_looks_terrible/dr5l2k2/) 360 Extreme Explorer v12, a Chinese Chromium 78 fork, that is able to run on Windows XP SP3 onwards, does not suffer from this issue; you'd better flip the flag #enable-javascript-harmony to Enabled (followed by a restart) and you can use latest reddit without issues (including infinite scrolling...) : (the above is with build 12.0.1268.0 and dark skin/forced dark mode... )

... I think you did not view the screenshots posted by @RainyShadow ; the issue isn't that the about:support internal page doesn't load; it does, but it isn't populated with all the expected info/details one should find there: Reproduced on a new/clean NM27 profile, on Vista SP2 32-bit

If anyone of you, XP diehards , uses Transmission as a bit-torrent client, I have posted the bad news over at the Vista subforum:

Just like qbittorrent towards the end of last year, another open-source bit torrent client, Transmission, has progressed past Windows Vista (and XP) support ... Transmission is a well known bit-torrent client, especially popular among Mac users, preffered due to its low memory footprint on the host system; its home site is hosted at: https://transmissionbt.com/ while the open-source code is hosted at GitHub: https://github.com/transmission/transmission While the back-end is cross-platform, the Windows port/front-end builds on the popular Qt Framework (much like the Windows port of qbittorrent); over the last two years, official releases appeared to have remained stagnant at version 2.94 (issued on May 1st 2018), built with Qt FW 5.6.0. Some days ago, new official release v3.00 came to light which, most sadly, has minimum WinOS requirements met by Windows 7; v3.00 has been built using Qt 5.14.2 which, by itself, denies any XP+Vista support; earlier in this very thread it was detailed that the last Qt version with FULL Vista support was 5.6.3 (with some rare app exceptions cited that manage to run under Vista while built on Qt 5.7.x/5.9.x); it's still possible, because I haven't bothered to check, that the core Transmission code now intentionally targets Win7+ and thus the breakage is not entirely due to the move to a higher Qt version ... To cut it short, Transmission v2.94 from 2018 is now the EoS'ed version for both Windows XP SP3/Windows Vista SP2: (official links to MSI installers:) transmission-2.94-x86.msi transmission-2.94-x64.msi With the popular (but adware/bloatware/spyware) uTorrent application having abandonned XP+Vista several months ago, the addition of Transmission (along with qbittorrent) to the list of bit-torrent clients that aren't maintained anymore under Vista limits extremely the choice of such a client under that OS (with, off-the-top-of-my-head, the closed-source Tixati being one of the last available choices... ) ...

@dencorso : Methinks the above two posts are just outright "plug" attempts for the referenced payware software manufacturer ; new MSFN user @rryan22 has just subscribed 6 hours ago with the (apparent) sole intent of making those two posts... And while the country of origin has been declared as the UK, the quality of the English language used points more to a translation machine/web bot, e.g.: Just to be on the clear, I have nothing personal against payware (coders certainly have to make a living) or people without an adequate command of the English language (which is the default in these forums...). However, unless @rryan22 has personally tested every individual piece of payware software he has mentioned as the last one working on Vista/Win2k, then I'll continue to treat his posts as disguised advertisement attempts... BTW, should any of the claims made be true, why isn't a transparent approach of accessing those older, still payware, software versions offered?

... About the france.tv issue: Troubleshooting from outside of France: 1. Geo-block circumvention As one would expect, this is a media portal site which streams copyrighted audio-visual content, intended for a specific country/region (in this case France); I haven't bothered checking one of their LIVE streams (which are usually the ones most heavily protected against "illegal" access), but chose a VOD URL: https://www.france.tv/france-2/eurovision-europe-shine-a-light/1468469-emission-du-samedi-16-mai-2020.html They first check geo-location via https://player.webservices.francetelevisions.fr/v1/geoloc where they note the requesting client's timezone, plus they then check actual physical location via https://geoftv-a.akamaihd.net/ws/edgescape.json These APIs can't be fooled with an "X-Forwarded-For" request header hack, so to pretend to be in France you'll have to use a whitelisted French HTTPS/SOCKS proxy or a French VPN... One good source of "open/misconfigured" French proxies suitable for such tests is http://spys.one/free-proxy-list/FR/ I picked one with small latency and good speed (http://195.154.41.246:5836) and configured New Moon 28 to use it for all connections... 2. Actual testing I used the latest NM28 offering (package: palemoon-28.9.3a1.win32-git-20200516-a8f7300b9-uxp-9cf4eca9a-xpmod, buildID=20200515224638) with a new, pristine, profile. I verified the issue reported by @IXOYE with the French proxy in use; thankfully, the screenshot of the NM28 Error Console (btw, the poster was asked to provide Web Console logs, which would've been more verbose, better for troubleshooting) mentions "polyfill.io/v2" and this started ringing some bells... It turned out the "france.tv player" issue had been already previously reported in the upstream support forum: https://forum.palemoon.org/viewtopic.php?f=3&t=24269 and the cause is that sites still using the old polyfill.io/v2 library (the current is v3) break in Pale Moon (hence NM), because v2 doesn't detect NM's features well and chokes (more: https://forum.palemoon.org/search.php?keywords=polyfill) ... The workaround is to use a SSUAO for "cdn.polyfill.io" advertising latest Mozilla Firefox: general.useragent.override.cdn.polyfill.io;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:75.0) Gecko/20100101 Firefox/75.0 This fixes the issue for me, at least on NM28 and a VOD: However, be warned that the SSUAO suggested above, while it does fix the france.tv issue, it may break other websites which also use polyfill.io, especially if they have upgraded to its version 3... FWIW, NM28 is being served by france.tv player MPEG-DASH unencrypted (no DRM) streams, which are also geo-fenced at the manifest/CDN level ; one MPD manifest I managed to sniff is of the template: https://cloudreplayfrancetv.akamaized.net/7400cc4850ce5/229118575_france-domtom_TA.ism/manifest.mpd?hdnea=exp=1589845397~acl=%2f7400cc4850ce5%2f229118575_france-domtom_TA.ism*~hmac=79fe0976ca3c2982afbf17e1ba2e4d06255857c968f01229a33f37cb5c712cd9 If/when france.tv move to full encryption/DRM, requiring current Widevine support in the browser, then it'd be game-over for XP/Vista users, because latest widevine DLLs require Win7 as a bare minimum...