VistaLover

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

Apologies , it was somewhat inconsiderate of me to wish you Happy Easter, while you are in mourning over your recent loss ... But, life must go on, as we say here: "The Dead among the Dead and the Living among the Living"; peace with you and your loved ones... Covid19-wise, it's the same SNAFU over here, too...

Many thanks, indeed! palem's post there is, I think, highly representative/reflective of the major part of Moonchild browsers' userbase, and should also encompass users of Roytam1 forks here... The actual URI of the post (by M.A.T.) quoted is: https://forum.palemoon.org/viewtopic.php?p=211976&sid=0181647fb5c2204a1c681cd16e21004d#p211976 ... As far as I know, no-one here has already gone/will go nuts over it, all is needed is to keep a vigilant eye on UXP+PM issue trackers/UXP+PM master branches and selectively revert/omit what is deemed unneeded for our tree... Even if that, eventually, will just buy us more time (hopefully lots of it...), it would be highly worth it! E.g., I have already warned readers here of the new plan (envisioned by M.A.T.) to move to an install.json based extension ecosystem (deprecating the install.rdf one), I think these developments should be dealt with on a case-by-case basis/when they present themselves... OT: To Sampei and to all observing Easter tomorrow, may you have a very Happy Easter Sunday (... Unfortunately, divisions between communities of the same Faith mean that over here Easter Sunday won't "arrive" until May 2nd ) ...

... Modern Wakandan? Really Moonchild? https://freefontsdownload.net/free-modernwakandan-font-160865.htm Anyhow, blocking remote fonts in uBlock Origin "legacy" fixed it for me... Well. I was well on April 2nd (by 5 hours) in my timezone already, so that wasn't my first thought... In a devilish coincidence (or perhaps it was deliberate all along), the official PM forums were down for maintenance, because going there to look for answers was what I did first, before posting here... Now that their forums are back, all has been revealed: https://forum.palemoon.org/viewtopic.php?f=37&t=26503 https://forum.palemoon.org/viewtopic.php?f=17&t=26504 Thanks everyone for your input...

In his latest Pale Moon extension-blocklist update, Moonchild, among other changes, moved to "severity 3" (hard/permanent block) the following two extensions: Giorgio Maone's (legacy) NoScript (id="{73a6fe31-595d-460b-a920-fcc0f8843232}") JustOff's Moon Tester Tool (id="moonttool@Off.JustOff") and added directly at "severity 3" level () JustOff's Classic Add-ons Archive (CAA) (id="ca-archive@Off.JustOff") Code below: https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/1ca7c78 I don't know whether it's a typo (probably not...), but the commit's title says it "fixes" PM issue #1444 , which has nothing to do with the extension blocklist... The latest update is in fact just another coordinated offensive against JustOff's offerings (previous ally, now treated as worst foe...). @roytam1 : Are New Moon 28 users being served the same blocklist as Moonchild's PM? Browsing inside NM28's "about:config" section and filtering for "extensions.blocklist", I see: extensions.blocklist.url;https://blocklist.palemoon.org/?version=%VERSION% but what is the value of %VERSION% in our case (if it's 28.10.3a1, then the resultant URI redirects to https://blocklist.palemoon.org/v28-1/blocklist.xml which serves currently an older iteration of the blocklist... ) ? Might I kindly ask you to undo these changes (if indeed they'll affect us, too ), since many users here use one or more of the now permanently blocked PM extensions (I use MTT+CAA, NoScript also has some enthusiasts among NM28 users ...). Somewhat OT, but do you, too, see "hieroglyphs" on everything hosted on www.palemoon.org: I noticed this when trying a NM28 fresh profile and was greeted with http://www.palemoon.org/firstrun.shtml FTR, the Page Source is correctly in English, but when the page loads, only displays English for a mere fraction of a second, then falls back to indecipherable scripts; I have tried several character encodings, all to no avail...

@Montana Slim : [App] Vendor=Hyperbola Name=Icedove-UXP Version=52.9.20210325 BuildID=20100101 ID={3aa07e56-beb0-47a0-b0cb-c735edd25419} RemotingName=Icedove-UXP [Gecko] MinVersion=4.8.0 MaxVersion=4.8.0 ... and [App] Vendor=OpenSource Name=MailNews RemotingName=mailnews Version=52.9.7754a1 BuildID=20210325050411 ID={3550f703-e582-4d05-9a08-453d09bdfdc6} [Gecko] MinVersion=4.8.0 MaxVersion=4.8.0

In my previous post in this thread, I assumed you were trying to just connect to https://www.catalog.update.microsoft.com/Home.aspx (because that's the URL I have bookmarked for MUC), so that's why I posted the results of SSL Labs on hostname www.catalog.update.microsoft.com : It later became apparent (first via your IE8 screengrab ) that you wanted to access https://catalog.update.microsoft.com/v7/site/Home.aspx which is, as you stated, a different story, because it has a stricter (pun intended) HSTS (courtesy, again, of SSL Labs/Server on the "catalog.update.microsoft.com" hostname) : Because XP doesn't support EC Cryptography (ECC), there's sadly no way you could connect natively with IE8... Another factor that is/was not clear is the level of your Windows Update (XPSP3 EoS, POSReady2009 EoS, etc.); judging by what @Usher has posted above, I gather that a POSReady2009 EoS level updated IE8 is able to connect successfully to https://www.catalog.update.microsoft.com/Home.aspx (via one of the TLS_RSA_WITH_AES_* cipher suites, possibly over TLS v1.2, too - POSReady2009 has indeed brought TLS v1.2 to XP...), so that should be the way to go on XP (until M$ ruin it further in the future, which I'm sure they will ). As @Dave-H has correctly advised , if your default ProxHTTPSProxy configuration file (config.ini) has the following entry under its [SSL Pass-Thru] section: [SSL Pass-Thru] *microsoft.com* you just have to comment it out, so that both MUC variants are being "proxied": [SSL Pass-Thru] #*microsoft.com* Best wishes

Pardon me if I didn't get this right , but does that (greyed-out) McAfee tray icon belong to Web Advisor? From previous discussion, I got the impression Web Advisor is a browser extension/plugin... In any case, in a recent McAfee support article, they noted that the legacy McAfee products that were compatible with XP (& Vista) are no longer able to receive definition updates since Jan 1st 2021 , which might explain the greying-out and the (white) exclamation mark in a red background - this is me assuming the icon belongs to one of these legacy McAfee products... If, OTOH, the tray icon does belong to Web Advisor, which is still able to receive def updates (and user has set it in "manual" mode and delayed updating it), then this sets an exception to McAfee's support policy wrt XP...

I'm afraid that the next version of MediaInfo.dll, with announced loss of XP support, will also mean the death of MediaInfoLITE under Windows XP ; the GUI (which is indeed XP-compatible and not expected to change) is just a front-end for the info obtained by the DLL; when the DLL won't work in its future versions, I expect the GUI to either be devoid of info or not load at all... Time will tell ... As with the full-blown MediaInfo application, you can always stay on version 21.03 of the DLL to continue using MediaInfoLITE under XP ... Cheers

Yes, the Explorer integration is its major asset! But, even beginning with my Windows XP era (2005-2009), what I use till now specifically for Explorer context menu is the, so called, LITE version of MediaInfo, which just comprises a minimalistic GUI (executable made by Atak_Snajpera, a doom9 developer) and the official MediaInfo.dll file (which can be updated independently of the GUI, by downloading the MediaInfo_DLL_xx.xx_Windows_i386_WithoutInstaller.7z package from MediaInfo author). The GUI hasn't changed much over the years, it was initially developed as part of the Tools section of early-XP era K-Lite Codec Pack versions, that's how I was introduced to it and stuck with it ever since... More about MediaInfoLITE below: https://www.softpedia.com/get/Multimedia/Video/Other-VIDEO-Tools/MediaInfo-Lite.shtml VideoHelp also host a link for the latest version: https://www.videohelp.com/software/MediaInfo https://www.videohelp.com/download/MediaInfoLite2103.exe Cheers

... Which was exactly the point of my post; you were quick to dismiss the info I posted here, out of pure courtesy to my XP friends , without first verifying it yourself (and making me look "bad" along the way... ). FTR, I didn't direct XP members to a random "videohelp" URL, but specifically to https://www.videohelp.com/software/PotPlayer/old-versions and, more accurately, to VideoHelp being a third party provider, I did not want initially to post direct links to packages (Forum rule 1.b), but I have now done so above, for XP-members' convenience; to the best of my knowledge, these are original/unaltered/official binaries being re-hosted (and the 21-02-09 builds not to be found on vendor's site). You declined my plea to test for yourself; for closure, can another kind soul that happens to use XP SP3 32-bit (SSE2) please check those builds above and verify they indeed install and work OK (so this issue could be put to rest...) ? @FranceBB (from memory I recall as being an avid PotPlayer enthusiast), would you oblige? Water under the bridge here , thanks for your many and valuable contributions...

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... The forks by feodor2 (Mypal, Centauri) follow almost to the letter (errr, number ) the official versioning, so the extension would have no issue (that I know of) installing and functioning there; so, that only leaves out the forks by @roytam1 ... Successful operation of the extension (i.e. GitHub working the way it is expected by a Github user) doesn't only depend on appVersion, but the underlying platform (UXP) has to have a minimum set of required features (be "mature" enough, if you will) to support the polyfills loaded by the extension; and UXP snapshots prior to Oct 2020 lack one or more of these features; e.g., the Preview tab in the comments section (for a logged-in user) requires the abortController web API. Imagine the case your wish has been granted by @JustOff and his extension installs out-of-the-box in Serpent 52.9.0; not so long ago we've seen posts in this thread about how more responsive yesteryear versions of Serpent 52.9.0 are, recommended in a subtle way to users on low-end hardware XP systems... 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? FWIW, you created your GitHub issue being a Serpent 52 user; under the same reasoning, shouldn't the New Moon 28 users be entitled to out-of-the-box support, too? But NM28 last October was at version 28.10.2a1, so if @JustOff enables such support, the extension would be half-working (if at all) when installed in official Pale Moon < 28.14.0 (this is also an edge case, but who knows if it doesn't come up?) ; 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...

... Below is the test for "www.catalog.update.microsoft.com" on SSL Labs/Server: https://www.ssllabs.com/ssltest/analyze.html?d=www.catalog.update.microsoft.com As one can see, it also offers connection over TLS 1.0+1.1, with weaker cipher suites (e.g. TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)); however, as you posted, IE8/XP isn't able to connect, and this is indicated further down below, in the "Handshake Simulation" section; the deal breaker in that case might also be the lack of SNI support in IE8 under XP, as well as lack of available cipher suites... It's a good thing, of course, that the catalog is no more an ActiveX-exclusive (read IE-only) site, so it can be accessed on XP via alternate browsers (SSL Labs claim that even Chrome 49/XP SP3 works...). Best regards , welcome to MSFN!

Well, I lost my sleep but I think I did solve this mystery! Of the versions currently present in the GitHub repo, https://github.com/JustOff/github-wc-polyfill/releases only the very latest at the time (now @v1.1.8) is able to be successfully installed in St52 by directly clicking on its .xpi link Attention: this is a left click, not "Save As" context menu (right) click! The browser will then ask you to grant github.com permission to install "software", click "Allow" and then will come the prompt to install! I don't have a full explanation based on documented literature for the above behaviour, but it appears that what takes precedence, in the above scenario, over the <em:minVersion>52.9.2020.10.05</em:minVersion> requirement inside the add-on's install.rdf file is the content of line: <em:updateURL>https://raw.githubusercontent.com/JustOff/github-wc-polyfill/master/update.xml</em:updateURL> inside that same file, which always points to the latest version, but with a different <em:minVersion> of just 52.9: <?xml version="1.0" encoding="UTF-8"?> <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="http://www.mozilla.org/2004/em-rdf#"> <RDF:Description about="urn:mozilla:extension:github-wc-polyfill@Off.JustOff"> <em:updates> <RDF:Seq> <RDF:li> <RDF:Description> <em:version>1.1.8</em:version> <em:targetApplication> <RDF:Description> <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id> <em:minVersion>28.14.0</em:minVersion> <em:maxVersion>29.*</em:maxVersion> <em:updateLink>https://github.com/JustOff/github-wc-polyfill/releases/download/1.1.8/github-wc-polyfill-1.1.8.xpi</em:updateLink> </RDF:Description> </em:targetApplication> <em:targetApplication> <RDF:Description> <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> <em:minVersion>52.9</em:minVersion> <em:maxVersion>52.*</em:maxVersion> <em:updateLink>https://github.com/JustOff/github-wc-polyfill/releases/download/1.1.8/github-wc-polyfill-1.1.8.xpi</em:updateLink> </RDF:Description> </em:targetApplication> <em:targetApplication> <RDF:Description> <em:id>{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}</em:id> <em:minVersion>2.53.4</em:minVersion> <em:maxVersion>2.53.*</em:maxVersion> <em:updateLink>https://github.com/JustOff/github-wc-polyfill/releases/download/1.1.8/github-wc-polyfill-1.1.8.xpi</em:updateLink> </RDF:Description> </em:targetApplication> </RDF:Description> </RDF:li> </RDF:Seq> </em:updates> </RDF:Description> </RDF:RDF> So, the latest version will ALWAYS install , but previous versions, for which the "update.xml" URI is non-relevant, WON'T install (directly from GitHub or via drag-n-drop as downloaded files beforehand), because in that case the <em:minVersion>52.9.2020.10.05</em:minVersion> condition is in effect, not the <em:minVersion>52.9</em:minVersion> one, exclusive to the latest version at the time... Hope all this makes sense to the rest of you now...