VistaLover

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

Yes, as I already wrote (and have posted screengrabs as proof), I didn't have to tinker with the install.rdf file of 1.1.8 to get it successfully installed and enabled in latest St52 v52.9.0 (2021-03-25) (32-bit) ! You said yourself that its previous version 1.1.7 was installed and working, did you also get it installed in the first place via messing with its install.rdf file? Because, if you download v1.1.7 from GitHub and again inspect its install.rdf file, you'll find it has the same <em:minVersion> requirement as latest version 1.1.8: <Description> <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> <em:minVersion>52.9.2020.10.05</em:minVersion> <em:maxVersion>52.9.2021.*</em:maxVersion> </Description> Editing the install.rdf file of 1.1.8 to get it installed only masks/works-around some profile issue (the same issue that won't have 1.1.7 re-install and work again), the "strange" thing is I can't think just now what the culprit could be... Have you (or an extension, a custom user.js, etc), by any chance, toggled pref extensions.strictCompatibility ? => Read below...

... Something's amiss in your current profile, then... I had no issues updating it in my dirty St52 profile, just to humour you I tried with a fresh Serpent 52 profile too, no issues whatsoever:

My dear @Sampei.Nihira, I beg to differ... Have you tried the 32-bit files yourself? You are usually correct 99% of the times , but this is just the 1% you're not ... I have downloaded myself the "videohelp" file https://www.videohelp.com/download/PotPlayerSetup-210209.exe and afterwards the one you uploaded yourself http://www.filedropper.com/potplayersetup and you know what? They're completely identical (with the very same digital signature) : Please, kindly check yourself the 210219 (32-bit) referenced VideoHelp archive files (setup/portable) and please retract... It's enough having been recently accused that 70% of my (5-year-long) post count is OT, I don't want to be also accused of spreading untruths... Kind regards

It would appear that the Korean archive above does not hold all released versions, however, thankfully , the archive maintained by the well-known site "www.videohelp.com" does : https://www.videohelp.com/software/PotPlayer/old-versions It does, indeed, contain the version mentioned by @Sampei.Nihira : ; BTW, I have no affiliation whatsoever with linked site, I have not tested myself the validity & well-functioning (under XP) of referenced builds/packages, use your common sense when downloading and installing...

I'm not an expert on Chromium-derived browsers, take this as a "disclaimer", but SU informs me this is probably only possible via userscript/extensions: https://superuser.com/questions/1122215/how-to-disable-beforeunload-events-e-g-are-you-sure-you-want-to-leave-this-pa https://superuser.com/questions/705307/how-can-i-disable-are-you-sure-you-want-to-leave-this-page-popups-in-chrome/705308 Archived userscript (to try): https://web.archive.org/web/20150919231349/http://javascript.about.com/library/exitblock.user.js Some extensions on CWS to try: https://chrome.google.com/webstore/detail/no-beforeunload/dlnlkhegmifbcipdgpggedmjdaganmei https://chrome.google.com/webstore/detail/alertblock/mldjhdofddgiaelidingjcnenlblbfgn https://chrome.google.com/webstore/detail/let-me-out/hnfdibcbmlppjlkefinedeffoiomlecc https://chrome.google.com/webstore/detail/navigation-confirmation/hneikegkjmchoaghaahefkhecifdibpk https://chrome.google.com/webstore/detail/navigation-confirmation-b/hchjkkahngaaboddjlaghmcephdheofg A test URL would've helped, BTW...

<OT> ... OK, I've now gotten hold of that laptop of hers and... Thank you very much for responding to my plea! Yes, on a new Fx 87.0 portable profile, about:support is fine... I had also tried Safe Mode on her old/dirty profile, but the issue persisted, so it's definitely something gone awry in that used profile... Thankfully, Bingo! That was exactly it! You are a true gem! That .json file was not present in the old/dirty profile, having been migrated through several Firefox versions, over time... Although. this makes me wonder WTH such a file has to do with populating the about:support page? This is the stable/release channel of Firefox (i.e. v87.0), are they (Mozilla) now conducting experiments there? After Mozilla dropped Vista support (too soon if you ask me, Fx 53/54 could have been made Vista-compatible), I became estranged from the inner workings of their Quantum Browser (only to discover later they even dropped that "Quantum" part...), this new issue I stumbled upon just proves to me how "twisted" things have become at MozillaLand... @DanR20 , I owe you... </OT>

While I did find that post of yours to be of value/merit , soliciting "likes/upvotes" in such a blatant way is not something to my liking... But that's just probably me getting older...

<OT> Apologies for the OT, but my sister relies on latest Mozilla Firefox (87.0) for her work on her Windows 7 SP1 64-bit laptop; the version used is the portable edition (in PAF format) of the Greek-localisation of the 32-bit official compile: https://ftp.mozilla.org/pub/firefox/releases/87.0/win32/el/ Except for facebook (), twitter () and instagram (), what I personally consider the most detrimental places to visit on a (non-Google) desktop browser, she's basically clueless about IT, so I'm often summoned for troubleshooting on her machine... On such a recent occasion I found out, to my dismay, that the about:support troubleshooting help page of Fx 87.0el 32-bit remains empty of vital details... I've googled and nothing relevant came up - since she's constantly in front of that machine (ca. 16h/day) and I can't run Fx 87.0 under Vista SP2 32-bit, can someone kind try to investigate this? Is about:support populated with ALL info on a non-English localised Fx 87.0 (32-bit) instance? Thanks </OT>

<OT> Thanks, but the discussion here has always been about decompressing resources.pak of the XP(/Vista)-compatible YB v17.4.1.x ( @ArcticFoxie cited v17.4.1.919, while the very last 17.4.1.x one is v17.4.1.1026 - and the one I unsuccessfully tried the GRIT plugin on... ) ; interestingly enough, the plugin does work in the Vista+ compatible v17.6.0.1633 (Chromium 58 based) I use here (portable PAF format), so whatever packing changes Yandex have implemented to .pak files must've been between the 17.4 & 17.6 branches (there was no 17.5 one) ... EDIT: AF has just posted as I was finishing composing this post... </OT>

Fx45ESR 20210327 builds are there, but under slightly different filenames: firefox-45.9.32-20210327-f3ee98666-win32-ia32.7z firefox-45.9.32-20210327-f3ee98666-win32-sse.7z firefox-45.9.32-20210327-f3ee98666-win64.7z However, MailNews/BNavigator/IceDove-UXP/IceApe-UXP builds of 20210327 haven't yet made it onto the server, hence the 404s...

<OT> Not true, support starts at Windows XP SP3 (am running 360EEv13 under Vista SP2 32-bit here) ! Many thanks for your suggestion of the GRIT 7-zip plugin ; however, while it does work for .pak files of the rest of the Chromium forks (including Google Chrome), it still is incapable of accessing and decompressing the insides of YB's resources.pak file ; as @ArcticFoxie has stressed, that file has been specially packed/crafted so as to be only accessible by the browser itself, not third party tools... I guess you could consider it a form of soft "encryption" ... But members here shouldn't act that surprised! To bring this thread tangentially back on track, Moonchild himself has started doing the same with his official Pale Moon releases some months ago (November 2020) ! Starting with PM 28.16.0, both resources files (./palemoon/browser/palemoon.res & ./palemoon/palemoon.res) have been brotli 1.0.9 encoded and header-modified (by a special py2.7 script at build-time), which renders them non-extractable by 7-zip or any other third party archiver, even the brotli 7-zip fork by Tino Reichardt (look here) ; and while for PM there exists a way to, at least, inspect the guts of palemoon.res files (previously named omni.ja), I haven't found one for Yandex Browser... FWIW, Moonchild claims that the Open Source licence of PM covers only that, the browser source code, but released binaries (compiled code) can be "manipulated" as deemed appropriate by their author, who doesn't want user-interaction with and decompilation of officially branded/patented files... JFYI, the same route has been followed by the Mypal fork... </OT>

Not really helping, I know, but under Vista SP2 32-bit I have no issues launching latest DTaskManager (v1.57.11); in Vista, Visual Basic 6 Runtime is an integral part of the OS, the version of file msvbvm60.dll inside system32 is indeed 6.0.98.2 (i.e. just like in your case...). The following article should be of eventual help to XP users: https://atrilsolutions.zendesk.com/hc/en-us/articles/205537331-How-to-re-install-the-Visual-Basic-6-Runtime The first redistributable installs msvbvm60.dll v6.0.97.82, the second one doesn't seem to contain an updated version of it... No doubt you got your 6.0.98.2 version via Microsoft Update (?) ... Perhaps your issue has a different root cause, only simply manifesting itself with a crash on msvbvm60.dll ?

<OT> You can try https://github.com/myfreeer/chrome-pak-customizer </OT>

It does require Windows Vista as a minimum, as it's clearly stated in the app's individual download page: https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck

@Jody Thornton The last 32-bit version of official Basilisk MCP (Moonchild) ever released was Basilisk-52.9.2020.11.25 That version was compiled without an auto-updater built-in, so will stay "put" there indefinitely... If you/your parents aren't overly concerned with security (the vendor of Win7 has stopped patching the OS - without a fee - since Jan 2020) and if their frequently visited sites are not in the habit of constant changes (usually for the worse), you/they should be covered where web compatibility is concerned for a few more months, at least... AFAIAA, that last version of Bk only supported the so-called "legacy" extensions (no WE), and the ones targeting pre-quantum Firefox would not have any problem installing there... Migrating the profile of Basilisk 52.9.2020.11.25 32-bit to Serpent 52.9.0 (32-bit) should be straightforward, except, perhaps, where stored account credentials are concerned, because MCP use different versions of the NSS library to the one used by @roytam1 ; more below... There are no plans here to adopt any breaking changes affecting the installation of pre-quantum Firefox legacy extensions (from CAA, GitHub or elsewhere...) on either Serpent/UXP or NM/UXP, as far as it's humanly possible - but no-one can guarantee you or your parents that an extension currently working fine on Basilisk-52.9.2020.11.25 (and which should behave similarly on latest Serpent 52) won't break in the future (near or distant, who knows?) when the browser engine/core itself progresses, under constant development, to tackle web compatibility issues of the future... If you are particularly concerned about CTT, I'm running v.1.7.8.2019.10.27 in latest St52 32-bit (buildID=20210319014823) and I currently see no issues whatsoever with it... But Aris has stopped developing it further, so the chances of a fix coming from him in the event of a future breakage (under St52) are slim... But, in my educated guess, major changes affecting the Australis interface of Basilisk (/Serpent) are quite improbable... Now, before migrating to St52 from Bk, make sure to first install a password exporting extension (e.g. https://github.com/JustOff/password-backup-tool/releases/tag/1.3.2 ) and export the stored accounts/passwords into a file; then, once on Serpent 52, install the same add-on there and import the same accounts/passwords from that saved file... Starting with a new/pristine St52 profile would be optimal. only transferring afterwards vital pieces of the old Bk profile (bookmarks, passwords, extensions, history, etc.), but I realise people pressed-for-time opt for cross-app profile transplantation; fingers-crossed, there's very little that could go wrong in the migration from Bk52 -> St52, so hoping for the best! Hope I've helped... @ArcticFoxie : Serpent 52 is no more a BETA browser than the already used Basilisk 52 one... But I generally agree with the gist of your post! Not quite the same, but I distinctly remember how difficult it was for my late father (God rest his soul) to adopt, at 75 then, to the changes made from analog terrestrial TV to digital terrestrial broadcast (DVBT); we decided to let him continue using the old TV set he was familiar with, but connect it to an external DVBT standalone receiver, boy was that hard to teach him using that! Best regards... Later edit: Nope, it's made by a member of the MCP team, Lootyhoof: https://repo.palemoon.org/Lootyhoof/photonic In fact, I'm already using this here, with custom modifications to make it Vista compatible:

; though I can't code (but at the same time I feel I have pointed you to the right direction ) and am not a user of said extension, I must publicly express my personal admiration+respect towards you, for taking personal time to cater to one of your users that does use that add-on! Your dedication speaks volumes!