VistaLover

@Sampei.Nihira : In latest Serpent 52, I only use uBlock Origin 1.16.4.28 ; when I first ran the test, I got a score of 84% ; enabling the built-in AdGuard Tracking Protection filter list, it goes up to 90%; however, tracking down which hostnames were allowed in the tool's results, and creating global "block" rules in uBO: * analytics.facebook.com * block * analytics.pointdrive.linkedin.com * block * widgets.pinterest.com * block * analytics.pinterest.com * block * trk.pinterest.com * block * appmetrica.yandex.com * block * yandexadexchange.net * block * analytics.mobile.yandex.net * block * extmaps-api.yandex.net * block * adsdk.yandex.ru * block * data.mistat.xiaomi.com * block * data.mistat.intl.xiaomi.com * block * data.mistat.india.xiaomi.com * block * data.mistat.rus.xiaomi.com * block * logservice.hicloud.com * block * logservice1.hicloud.com * block * logbak.hicloud.com * block * insights.samsung.com * block * analytics-api.samsunghealthcn.com * block * supportmetrics.apple.com * block * metrics.icloud.com * block * metrics.mzstatic.com * block ... I can get 100% : (... without enabling AdGuard Tracking Protection list, which is quite a big one... ) . FWIW, another tester tool can be tried on: https://adblock-tester.com/ Happy blocking everyone...

Binary Outcast's "DOM Inspector" extension is install-able in Borealis Navigator, perhaps installing that in bnavigator will help? https://interlink-addons.binaryoutcast.com/addon/dom-inspector/ In this post of the now closed "Part 2" thread, my friend (I hope) @Dave-H wrote: Well, I didn't say that "current" Firefox is now WebKit/Chromium based per se, did I? This isn't (yet?) the case of Microsoft Edge abandoning its initial engine (EdgeHTML) in favour of the Chromium one (becoming now what most, affectionately, call "ChrEdge"), or even the case of original Opera moving from Presto to Webkit ... But, make no mistake, they are using Chromium code inside the current incarnation of their browser engine... So, technically, not Webkit/Chromium itself, but at the same time very closely related to it (while not being called that) ... In a somewhat broader spectrum, one must take into account the close affiliation that exists between Google and Mozilla: Mozilla Firefox ships with "Google Search" as its default search engine and this fact alone is a major source of income for Mozilla; Google pay them big because they get to harvest all this telemetry data from Firefox users (not bothered to change the default search engine to something else...). Apparently, telemetry data from Firefox is worth a lot to Google, so their devs take extra care when introducing (on their own, most of the times) "new" web standards and other Chrome-isms that these could be ported fairly easily to "current" Firefox; on the Mozilla camp, the devs, via the "Chrome-parity" policy, are quick to implement these Chrome-isms into Firefox, too, because if users leave Firefox (to Chrome) as a result of a popular site (e.g. Facebook) malfunctioning, Mozilla will lose revenue from Google and other sponsors... Also, Google do need the existence of at least one other "competitor" (but not really ) browser in the market, or else they'll get hit with anti-trust/monopoly lawsuits in the US and other territories... Do you now see the whole picture? In closing: Don't be surprised that "things" that are originally designed by Google for Google Chrome work well with latest Mozilla Firefox; it's a case of "symbiosis" between the two... Cheers (and apologies for the OT...)

Same here: The failing javascript code appears to be related to the jquery script below: https://aws1.discourse-cdn.com/arduino/assets/ember_jquery-36a23101c869ab0dc53fc908de69adb785731593573d32bdeef416acc1076ef4.br.js I suspect the "requires Javascript features not implemented in NM27" diagnosis applies here, too...

... With all due respect, "current" Firefox, as in ex "Firefox Quantum" (v>56), now "Firefox Browser" (latest is v88.0), is but a mere "Chromium" fork itself in so many ways under the hood/bonnet, that only its front-end somehow differentiates it from "proper" Google Chrome ; in what is known as "Google-parity" among Mozilla devs, they have been constantly aping all "Chrome-isms" over the last years to the point I, myself, consider current Firefox as yet another Chromium clone... FWIW, I have been following Firefox's "progression" ("regression", if you ask me ...) quite closely over the last decade or so, having been a Nightly Tester with a Bugzilla account since Firefox v21 ... So, I'm not really taken aback that Google Drive does work "fine in current versions of Firefox" , I'll have to side with @ArcticFoxie on this: Google make sure "their" Services work best/exclusively on Chromium derivatives and current Firefox can be considered as being one of them... Another case in point is the Google-owned Widevine CDM, which currently only works in "Chromium" browsers and current Firefox; in fact, Firefox's implementation of WV is almost identical to the one in Chrome, so much so that when Moonchild tried to backport it to official Basilisk 52/UXP, he failed miserably; that "pure" Chromium code was impossible to adapt to Fx52esr derived UXP, as a result, Basilisk is being shipped with broken WV since August 2019 (!) ; MCP's plan is to remove WV support altogether from that browser ... Cheers

Thanks! ; the updated extension can be downloaded from APMO: https://addons.palemoon.org/addon/decentraleyes/ or from author's repo: https://git.synz.io/Synzvato/decentraleyes/-/releases/v1.4.3 However, it being a Jetpack SDK (restartless) "legacy" extension, its days of being hosted on APMO are, sadly, numbered : M.A.T is determined to remove official PM's support for jetpack extensions and, eventually, purge APMO from already included ones...

What do you actually mean by "last" ? If you want the "last" version to install and run on XP, then I, sadly, don't know exactly what that is... Recent versions of the application require at least a Win7 (and, preferably, 64-bit) host machine ... FWIW, one can download official offline (standalone) installers for GEP v7.3.3/7.3.2./7.3.1/7.1.8 from: https://support.google.com/earth/answer/168344?hl=en FileHippo (and similar sites) have archived even older versions, try/use at your own risk...

Already posted:

@32bitforever : I don't have a Google account myself, nor will I create one now just for the sake of experimenting with Google Meet in latest Serpent 52 ... There may be several reasons why it doesn't work for you, e.g. 1. User-agent-sniffing; GM servers might not like the UA sent by your copy of Serpent 52 2. GM webpage / APIs might need browser technologies (e.g. Web Components, ShadowDOM, etc.) that are not yet complete/implemented in St52 and are particular to Chromium forks ... 3. GM APIs might not like the (older) implementation of WebRTC present in latest Serpent 52 ; while "upstream" claim it is still specs-compliant, Google have a habit of rejecting everything else that isn't tailored to their own "vision" () of Web 2021... Tools -> Web Developer -> Web Console/Browser Console/Error Console may give some clues as to your predicament... If you have access (through a sibling/relative/friend) to official Basilisk builds (require Win7 SP1 64-bit at minimum), you can try there, too; if still no go, little, if any, chance of fixing GM in our fork... And even if the issue persists in official Basilisk, again, very little chance "upstream" would even bother trying to fix it, as they harbour a known aversion towards Google-owned technologies, including WebRTC itself (which they haven't included in Pale Moon, BTW...).

You may also consider substituting the XP-incompatible openssl 1.1.1.x files with XP-compatible ones, like I advised for SUMo previously in this thread: Not tested here (XP is unavailable) ... BTW, the latest openssl 1.1.1 official release now is at version 1.1.1k (file versions 1.1.1.11)

Thanks for the heads-up! If you (or anyone else) can't wait until the (patched) version 3.0.13 is officially released, VideoLan provide VLC 3 automated nightly builds, where, hopefully, the exploit has been patched already ; latest (as of this writing) 3.0.13-dev-win32 build can be downloaded from: https://artifacts.videolan.org/vlc-3.0/nightly-win32/20210417-0625/ binaries repo: https://artifacts.videolan.org/vlc-3.0/nightly-win32/ Best wishes

The really interesting bits are to be found inside: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/9378 especially in comments by XP user @KOLANICH ... TL;DR : They didn't really have to drop XP, it was just that one of their devs (@mere-human) "forcefully" introduced code for a "modern" style File Open dialog, that relies on APIs found only on Vista+; the idea to have a fallback for XP was also dropped, as "too complicated"...

... FTR, I did warn about WebIDE having been kept "here" but removed by "upstream" : I'm sure Dutch speaking members here will appreciate your efforts! However, stay vigilant, more string changes on the way... https://github.com/roytam1/UXP/commit/700f7804bdfe9f8d6dbb9b5dae825a297dd16a34#diff-a4c8afcf877e09836666f13acf9d862c30c2b029439418d1afd4fd63f61c1a9d

Yes, but no common userscripts are shared between them... FWIW, I also have installed in that same St52 profile Stylem (a "legacy" userstyle manager, for styles that alter parts of the browser) and Stylus 1.14.23 (a WE userstyle manager) for styles that alter web pages - the latter also has support for the newer format of userstyle called UserCSS (offers configuration choices post-install); sadly, v1.14.23, the last compatible with St52, has become now quite old, several of the newer UserCSS styles won't install or previously installed versions won't update to the most current... One such example is Old Reddit Favicon : // ==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); }) (); A WE (like VM) could never alter a tab's favicon for a given site... Regards

I use the open source Violentmonkey extension (WE, currently at version 2.12.14) in latest Serpent 52.9.0, as well as in 360EE... VM being a WE, it can only affect web content, not browser looks (this is not possible in 360EE, of course, but I use Greasemonkey for Pale Moon in St52 to change several browser-GUI aspects...). https://greasyfork.org/en/scripts/410687-google-shut-up https://greasyfork.org/el/scripts/412178-youtube-dismiss-sign-in (has some overlapping functionality with the previous one) https://greasyfork.org/el/scripts/375525-youtube-age-verification-bypass (works only for embeddable age-gated videos) https://github.com/Mottie/GitHub-userscripts/wiki/GitHub-download-zip https://greasyfork.org/el/scripts/407745-bypass-github-ajax (in St52 and NM28, together with JustOff's GitHub Web Components Polyfill extension) https://greasyfork.org/el/scripts/395497-login-reminder-popup-remover https://github.com/Procyon-b/make-gis-great-again https://github.com/Procyon-b/GitHub-sort-by-recently https://cable.ayra.ch/tampermonkey/view.php?script=youtube_autoplay_disable.user.js (a must have!) https://cable.ayra.ch/tampermonkey/view.php?script=youtube_volume_normalizer.user.js https://greasyfork.org/en/scripts/5566-youtube-links (doesn't work in NM27) https://greasyfork.org/en/scripts/377047-old-reddit-redirect

... But it's coming from a Chinese vendor (so XP support isn't that much of a "surprise" there ... ); however, several members here have expressed their mistrust (some even aversion) for everything with a Chinese origin ; at the end of the day, would you yourself use such a solution? FTR, I don't have any personal issues myself using a Chinese (and/or Russian) product, that is, no additional issues compared to using just US/EU ones... Best regards

... I think they have been candid about the type of "continued support" in the May 17th 2018 article below: https://forums.malwarebytes.com/topic/191650-malwarebytes-3-frequently-asked-questions/?tab=comments#comment-1243649 i.e. their "support" is limited, in practice, to just offering def updates, via a separate development track (they also make mention of "other maintenance upgrades", but only an actual (paid) user of the app can testify whether such "upgrades" ever took place... ) . Still, if you compare them to other vendors cited in this thread (who decided to cut-off updates on their XP/Vista compatible products), they do hold a higher place in my heart, because they acknowledged: See there, if it's still "possible" for them, why did the rest bail out ? One sane person would think that when an OS becomes unsupported by its vendor, third party Security Products should become even more effective in protecting the integrity of that OS (and their vendors could generate additional income in the process ); what did we see instead? Most AV vendors leaving "high and dry" the users of said OS (which may well have been paying customers until then) ...

If that is on Serpent 52.9.0, on latest build at least, javascript.options.jit_trustedprincipals is not an included pref by default ; I found a mention about it here : but that Bugzilla bug refers to a relatively recent Firefox version; further searches landed me on: https://github.com/arkenfox/user.js/issues/928 which states: new in 75beta but commented out by default //user_pref("javascript.options.jit_trustedprincipals", true); // [FF75+] [HIDDEN PREF] so, in all probability, it is not applicable to St52... If you're just picking up user.js files from the web, please make sure first they are valid for the version of the browser used; and remember, St52 != Fx52 (and, certainly, not later Firefox versions... ) ... Best wishes

Another tip already mentioned previously in this thread is to launch 360EE with the cmdline argument: --process-per-site so that tabs under the same domain (e.g. all facebook.com tabs) are loaded by the same unique browser process; I tested this briefly in the past, but since I never get to having more than 25 open tabs and very few, if any, among them share the same domain, I did not witness a noticeable reduction in RAM consumption (tried on 360EEv12/v13) ... YMMV, of course...

For the duration JustOff was the head of the official Pale Moon localisation project, he would maintain his own langpack (LP) GitHub repository, https://github.com/JustOff/pale-moon-localization/releases and his Pre-release LPs would target PM's unstable channel, with which NM28 has/had the closest affinity... Modifying the minVersion value inside the install.rdf file, to account for NM28's different versioning, would produce an installable and functioning langpack... This practice used to work up to a point in time (e.g. I know it worked till the end of May 2019, when NM28 was at v.28.6.0a1); but,"upstream" started making coding decisions that were deemed "unwanted" by the majority of members here; old code was kept by us, but removed by upstream (e.g. WebIDE inside devtools) and vice-versa, i.e. they introduced new code that was not adopted here... Whenever these code differences introduce string modifications (addition or removal), then the PM-targeting LP becomes incompatible with NM28 to a varying degree; slight modifications in parts of the browser you don't use often may stay unnoticed, but when major core strings have been altered, considerable breakage takes place, even to the point that the non en-US pack renders NM28 unable to launch with it; a "safety" mechanism then silently disables that LP and re-launches the browser in the default (en-US) locale... I wrote the above "summary" for the sake of those unfamiliar with NM's localisation scenarios; FWIW, roytam1, from the very start, said he would not provide himself LPs for his browsers, we, as fork users, were just lucky we could, up to a point, "freeload" the ones prepared for PM by MCP (and get all the hatred from them for doing so... ). Our (roytam1's ) source tree had already diverged significantly from upstream even before JustOff was ousted from the MCP localisation team, but lack of his "unstable" LPs currently means that a DIY person like you can't peek into them to find newly introduced strings there (that could be migrated to a NM28-specific LP); the sole source of PM localisation now are the LPs intended for its release channel, to be found: https://addons.palemoon.org/language-packs/ with NL on https://addons.palemoon.org/releases/pm-langpack-nl/ Save as .xpi file and extract with 7-zip, then look inside for new strings not yet incorporated into your own NM28 NL-pack; you have to be well versed in the folder/file structure of the LP, if you have a NM28 NL pack that used to work in previous NM versions, you can "build" on top of that and go forward towards more recent releases... You must use a file diff application (or a text editor) to inspect the string differences between the exact same files of the two LPs, so you can modify your DIY one accordingly (taking care to incorporate only the new strings needed by our fork, the PM file may contain other strings not compatible with NM). Indication of strings modification in code can be found also on roytam1's GitHub repo; whenever UXP and/or Pale Moon source files that have a path containing "*/locales/en-US/*" are being modified, this signals modification to the natively bundled en-US langpack; these modifications should be reflected (and translated into Dutch, where applicable) in your DIY NM28 langpack. For instance, for the "Media Formats" strings that you cited, the relevant commit is [Pale-Moon] Issue #1862 - Add media format controls in Preferences -> Content from which you can see the newly introduced (English) strings in file application/palemoon/locales/en-US/chrome/browser/preferences/content.dtd by loading: https://github.com/roytam1/UXP/commit/650abe2cb9eb02c14369a807a6225ebb053d0b17#diff-d3c90e964941daf05f84a5b5192bc0c94f6f629dcc424dd23e8f87cc766cd4f7 Many times, it is difficult to tell on which LP file to apply the string changes committed to source files, this ain't one of them : <LP root>\browser\chrome\nl\locale\browser\preferences\content.dtd In conclusion, the natively bundled en-US langpack is found split between NM28's two omni.ja files: ".\palemoon\browser\omni.ja\chrome\en-US\*" ".\palemoon\omni.ja\chrome\en-US\*" (use 7-zip to access); ultimately, these are all the files you have to translate into Dutch and then package appropriately (consult an existing LP) to make a functional NM28 nl-langpack.xpi; it ain't easy, is it? But I am open for any automation process you happen to be aware of (this extends to the rest of this community here ) ... Kind regards

Well, AFAIK, @JustOff only supports official Pale Moon, official Basilisk and SeaMonkey 2.53.x; he doesn't support pre-Quantum Mozilla Firefox (v52-56), nor any other Fx52ESR-based fork... (snipped) Imagine the case your wish has been granted by @JustOff and his extension installs out-of-the-box in Serpent 52.9.0; (snipped) The extension would have no issue installing in a 2018 build of Serpent 52 (on Firefox ESR 52.x.x, too), but obviously the GitHub experience there would be substandard... Do you think @JustOff is willing to deal with such scenarios? (snipped) ... so, things aren't as clear-cut as initially imagined; the ball is now in @JustOff's court, so let's wait for his reaction... ... And the man has spoken: https://github.com/JustOff/github-wc-polyfill/issues/21#issuecomment-813060443 ... Didn't I tell you so?

Twitter related upstream change targeting Pale Moon, applicable to New Moon 28, too: https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/4f00b12

Actually based on Chromium 69 - 360EEv12 is the one based on Chromium 78... Basilisk 55/Moebius was actually born by MCP as a fork of a snapshot of Mozilla Firefox 53.0a1 (yes, the Nightly channel); there's very little, if anything, backported from Firefox stable 54.0 or 55.0; in fact, MCP, right after forking, started removing features, so that Basilisk 55 was even inferior to release channel Firefox 53.0, feature-wise (especially in what concerns e10s and WebExtension APIs) ... MCP just gave it an appVersion=55.0.x for purely "sensationalism" reasons ... Today's Serpent 55, as maintained by Roytam1 (updated roughly once a month), is a mixed-bag, an experimental app where patches from Mozilla, TenFourFox and, mostly, UXP are being applied... As for the matter at hand, Chromium-derived browsers are notorious for gobbling up RAM at the speed of light... By design, each tab is run in its own browser process, add to that several other processes needed by the browser core and extensions, add the amount of RAM devoured by your ad-blocker extension alone and you get the picture... Session restore in Chromium browsers is also an issue, because the application has to spawn, after initial launch, ALL these additional processes to "resurrect" the tabs present in the previous session... I was first introduced to PCs when Windows XP was the OS du jour, with its IE6 fine (!) browser which, if you care to remember, did not support tabs - opening 150-300 browser windows was unthinkable at the time... When "tabbed" browsers came into being, people started abusing the feature, many ending up doing, what was later called, tab-hoarding ; but websites of yesteryear were mainly static HTML pages, so the impact on consumed RAM (my initial XP box came with 512MB!) was small; this allowed tab-hoarders to continue the type of workflow they had been accustomed to... But lately, certainly within the last 5 years, web-sites have turned into web applications in their own right, laden with omnipresent rich media content and heavy scripts; embedded videos and high resolution images are now obligatory to attain high Google-analytics figures (which is what drives webpage creation now), plus wizards to social media are everywhere (even here on MSFN...). Browsers are being served huge blobs of (minified) Javascript, Web Assembly (wasm) code, huge CSS files, HTML5 video etc., that have to be decoded and rendered locally by the browser engine ! Especially the design of the (very popular) Social Media sites (Facebook, VK, instagram, twitter, tiktok, youtube e.a.), targeting mobile devices with touchscreens, with their "infinite-scroll" pages (where more content is loaded in memory as you scroll further), all that is a veritable menace to under-resourced and on "hardware-of-the-past" desktop machines... I am mentioning the above just to highlight the fact tab-hoarding has become a lot more difficult these days, especially on older (32-bit) OSes (which, by their nature, have worse RAM-handling/allocating capabilities than the recent 64-bit ones...). Don't get me wrong, I'm not passing judgement on @Cixert's workflow habits, just pointing out that his practice will simply get worse in the future, irrespective of browser/OS bugs... Pre-quantum Mozilla forks, like the ones issued by Roytam1, are basically single-process applications, which, by that fact alone, makes them more lenient on system resources; if you only have a few vital extensions, an intelligently configured content-blocker, you try to stay clear of desktop-hostile places like the main Social sites, then I suspect you can afford to open more tabs there... But remember, single process means that if one tab crashes, it takes the whole browser with it! On the subject of RAM consumption, let me also recommend the Lull-the-tabs legacy extension (by JustOff), which minimises significantly RAM consumption at browser start-up, especially when it tries to restore a large previous session... Looking for a similar add-on for Chromium browsers, The Great Suspender Original https://chrome.google.com/webstore/detail/the-great-suspender-origi/ahmkjjgdligadogjedmnogbpbcpofeeo sounds promising, but I've not tried it myself, since I never have more than 25 tabs open in 360EEv12/13 (several of which are system tabs that don't consume RAM). Some more extensions to try are mentioned in: https://www.makeuseof.com/tag/google-chrome-ram-memory-usage/ By the looks of it, Cixert has hit some session-restore bug on 360EEv11 that manifests itself under his specific usecase and/or OS configuration... In the following URL, https://www.webnots.com/8-ways-to-reduce-memory-and-cpu-usage-of-google-chrome/ I urge you to read chapters 2+3+4 ; if the session restore bug kicks-in at 151 opened tabs, then make sure you close the additional ones before exiting the browser; as others have said, you have to adapt to the browser's capabilities, should you wish to continue using 360EE... I'm not quite sure what is the exact OS/architecture this happens on, but later 360EE versions may fare better with regard to RAM management and session restore; have you tried 360EEv12 and/or 360EEv13? At the end of the day, if you find that none of the 360EE versions quench your work-related absolute need for 300 open tabs, you should consider staying with/switching to a browser that lets you do it... We can only help up to a point here, sadly... Best regards, stay safe

... A quick search found a few mentions (mostly in Chinese and Russian sites) of an interim release v1.7.21469.0 with the "version number", again, assumed to apply to the main potplayer.dll file ... That release, apparently, took place on Mar 25th 2021, and has already been superseded/replaced by (potplayer.dll) v1.7.21472.0 (that I downloaded directly from vendor: https://t1.daumcdn.net/potplayer/PotPlayer/Version/Latest/PotPlayerSetup.exe ); while searching, I did come across several PotPlayerSetup.exe releases with the same file version 1.7.21465, but with different versions of contained DLL and different digital sigs (DS): Setup v1.7.21465.0/DLL v1.7.21466]/DS 20210318 Setup v1.7.21465.0/DLL v1.7.21467]/DS 20210319 Setup v1.7.21465.0/DLL v1.7.21469]/DS 20210325 Setup v1.7.21465.0/DLL v1.7.21472]/DS 20210402 (latest as of this time) None of the above are expected to run under Windows XP... But, as I told already, standardisation of the released binaries has gone out the window... To be frank, I don't expect them to restore XP-compatibility, it might be a while before their main homepage reflects this, but it's the sad reality... FWIW, Vista will be also dropped like a hot potato at first opportunity, by introducing Win7+ function(s)... In light of the above sad developments, any further discussion of PP versions > 210209/1.7.21419.0 would be OT for this thread... Let me close by sharing another disturbing piece of news about current owners of PP: https://old.reddit.com/r/potplayer/comments/lxsozp/potplayer_official_english_forum_was_closed/ Thus, international PP users likely have to turn to third-party forums for support...

... Actually named PotPlayerXP.exe here: Too many inconsistencies with that latest release, if you ask me... 1. The installer has "File Version" 1.7.21465.0, but the main DLL (potplayer.dll) has "File Version" 1.7.21472.0 2. The "About" info shows application version (according to new naming convention) as being 210318 (i.e. Mar 18th 2021), this is the one VH also use, but the installer itself, PotPlayerSetup.exe, as well as the main DLL have been digitally signed on Apr 2nd 2021 : What a fine mess they've created, user confusion is inevitable...

I recollect this as having been already discussed in this thread... Upon searching, I did locate a post from June 2019, by one of your compatriots: I have never experienced this under Vista SP2 32-bit, so, as hinted, it might be an issue specific to XP... I am convinced, through local testing, that PotPlayer uses system resources (TLS implementation/cipher suites/crypto libs/cert store) to establish HTTPS connections, since (recently) many web services abandoned TLS v1.0/1.1 and moved on to TLS v1.2+, this might be a manifestation of such an implementation... A similar issue I'm facing with PP recently is its inability to play back several audio streams served securely, like the newly introduced BBC Radio Icecast ones, e.g. https://stream.live.vc.bbcmedia.co.uk/bbc_radio_one A test on SSL Labs shows it demands exclusively TLS v1.2 and cipher suites IE[9] can't cope with... The same stream plays back fine in VLC 3.0.x (which bundles its own crypto libs). This was indeed deduced from a changelog on subsequent (beta?) release 1.7.18193 two years ago, VH have since then a permanent link on https://www.videohelp.com/software/PotPlayer for what "they" claim to be the last XP-compatible version... OTOH, the very same site hosts, what I believe to be, a copy of the official stable releases changelog, https://www.videohelp.com/software/PotPlayer/version-history which jumps from v [1.7.17508] 2019/02/12 straight to v [1.7.18344] 2019/04/17 with no word about drop of XP support... That VideoHelp misconception/misunderstanding was also rooted among XP users based on the "H/W accelerated HEVC" debacle, read here ; FTR, stable release 1.7.18346 (second after 1.7.17508) was confirmed as being XP-compatible already in this thread by our very own PP guru! So, the moral of this short story is, don't always believe what you read at first, consult a second opinion, if you are a "Doubting Thomas" (like myself), try for yourself (except, of course, when "trying" goes against your principles - this is acknowledged and respected! ) ... Practically not "mine", merely hosted currently on VH - if you peruse this thread, you'll find I'm not the first one to suggest VH's archive as a source of previous PP releases... I genuinely thank you for your time and efforts conducting this conclusive test, which proves that the last, at the time of writing, XP-compatible release of PotPlayer is the one versioned [new scheme] 210209/[old scheme] 1.7.21419 . Lastly, it has been posted that the latest PortableApps offering of PotPlayer, package with filename "PotPlayerPortable_1.7.21419.paf.exe", has been erroneously declared as being XP-compatible, ie. in reality it isn't ... The above statement had me really perplexed, because @FranceBB has proven, beyond any doubt, that v1.7.21419 (packaged inside the PAF version) IS XP-worthy; the answer to my pondering is that XP-compatibility has been broken not on appVersion itself, but on the fact the packager omitted the inclusion of file PotPlayerMiniXP.exe inside ".\App\PotPlayer\" (in the PAF folder structure); this can be mitigated quite easily, if that missing file is 1. extracted (7-zip) from the installer of v1.7.21419 2. copied inside the PotPlayer directory (besides PotPlayerMini.exe, which you can delete, if on XP) 3. you modify the portable launcher's configuration, in ".\App\AppInfo\Launcher\PotPlayerPortable.ini" as below [Launch] -ProgramExecutable=PotPlayer\PotPlayerMini.exe +ProgramExecutable=PotPlayer\PotPlayerMiniXP.exe -: deletion of line +:addition of line Hope it works, it should... Best wishes