VistaLover

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!

... Well, that article dates back from Jan 27th 2019, so it isn't relevant anymore ; a lot of things have changed in the platform+application code since then, almost 25 1/2 months ago... Unlike "extensions-frozen-in-time", a browser being actively maintained evolves forward, its goal is the current web, not compatibility at all cost with abandonware... i.e. : ... and UXP issue #1257 was an important platform improvement, rightly merged IMHO, that got rid of Firefox-inherited, non-standard, JS feature that broke recent web compatibility ; from related UXP issue #1253 : Asking for removal of UXP issue #1257 related changes isn't the wise thing to do... As I wrote above, an actively maintained browser targeting the web of 2021 (which is, heartbreakingly, only Chrome-centered) must follow close the recent web standards (sadly now dictated by Chrome developers ), else major webpage breakage takes place and the browser becomes less useful for today's web-surfing needs (just look how deficient UXP browsers are currently due to lack of support for Web Components/Custom Elements/Shadow DOM and related Chrome-only web technologies ... ) . As the "upstream" devs believe, a constantly evolving modern-era browser shouldn't be held hostage by a few abandoned, old Firefox targeting, legacy extensions... As I recently posted, they have taken extreme measures in their own products to make sure browser development isn't held back due to some users being reluctant to part with their old Fx extensions... We have kept compatibility with Fx legacy extensions in our own UXP tree, but what should be the course of action from now on, when some of those legacy add-ons break as NM28 & St52 move along to tackle the web of 2021? Should these browsers be degraded in quality just to restore the functionality of abandonware? One thing's for sure, "old addon" breakage will definitely happen! Extensions supplement the browser, not the other way round... The removal of the "watch/unwatch()" functions did also break other extensions, like IHG (ImageHost-Grabber) and even JustOff's L4E (that I use on NM28); the latter was fixed by its author in v1.0.6 (Nov 2019), and that is the thing to do (i.e. fix the extension, not unfix the browser) ! If @roytam1 (am afraid this forum is short of JS/XUL developers ) is kind enough to take a look into zotero-4.0.29.25.xpi and is further able to patch it successfully (I remember reading back in the day that a watch/unwatch polyfill could be used in lieu of the removed functions), then you should be able to use that extension with current St52 (and you should thank Roy along the way...) ; if not, move on... Kind regards.

AFAICT, the portable distribution in PAF format, https://portableapps.com/apps/utilities/sumo-portable embeds the official ZIP edition which, as described previously, uses the XP-incompatible OpenSSL-1.1.1i for secure connections; it is my educated guess that the app runs in "degraded mode" under XP just because of openssl; SUMo can't reach securely the main server (Options->Settings->Get Update->SUMo Server) and produces the error you posted... But all hope is not lost, thanks to MSFN member @Reino ; aside from his XP-compatible FFmpeg builds, he also compiles and hosts XP-compatible versions of openssl-1.1.1, last one he's got available is 1.1.1i: https://rwijnsma.home.xs4all.nl/files/openssl/openssl-1.1.1i-win32-xpmod-sse.7z (i.e. not the very latest, which is 1.1.1j, but it'll do fine for SUMo purposes...). My suggestion thus is to download linked package, extract the two DLLs (libcrypto-1_1.dll+libssl-1_1.dll) and overwrite those provided with the SUMo 5.12 PAF distribution; my gut feeling is you'll be then able to connect successfully with the SUMo servers on XP (I have no way to test my theory on XP, so I'm waiting to hear back from you regarding this ... ) ! Best regards

If you read my amended post (with addendum), you'll hopefully understand why trying to modify the SSV value in the PE header of the sumo.exe setup file is, sadly, a no-go for both XP+Vista... Saluti da Grecia

I don't have access to the PRO (Full) installer, sumo.exe, but the "Lite" version, sumo_lite.exe, downloaded OK... "Not a valid win32 application" means the Sub System Version value of the PE Header has been set to > 5.1: You can try to lower that 6.1 version to 5.1 (with specialised PE tools) and see how it fares... Addendum: The installer is of the InnoSetup v6.1 format, so by simply lowering its SSV value in the PE header won't make it launch, sadly (and this includes Vista SP2, am afraid) ... More here : Regarding the zip edition, the main executable itself, SUMo.exe, has a SSV value of 4.0 in its PE header, so will have no problem launching under XP; the bad news (for XP) is that it uses, to establish HTTPS connections, the OpenSSL 1.1.1i library (libcrypto-1_1.dll+libssl-1_1.dll file versions 1.1.1.9), which itself requires Vista SP2 or higher...

I'm just plain frustrated to see yet another user of Serpent 52 UNDER WINDOWS XP post and seek help in the official Pale Moon (& Basilisk) forums: https://forum.palemoon.org/viewtopic.php?f=61&t=26414 Such actions only undermine further this project in the eyes of "upstream" and often lead to additional "counter" measures from their side... By pure luck, the OP was replied to by Moonchild, who used more moderate/civilised language... I don't want to even fathom the verbal abuse the OP would've been subject to, had he been "welcome" in the official forums by a certain M.A.T. developer... But in the above case, XP users who don't want to get informed themselves about the software (browser) they're using on that OS is only one part of the problem; OP is still unsure where to seek support for his predicament, trying Roytam1's GitHub repo for a start (only to be discouraged by GitHub's user-agent sniffing and the fact UXP browsers no longer support Chrome/Edge-targeting GitHub without installing a third party extension first... ). @roytam1, please make the header/banner in your blog's page more verbose; I personally know that comments there are indeed enabled, but that fact isn't at all apparent if you arrive there, much like the OP did (from God knows where...), by simply loading: https://rtfreesoft.blogspot.com/search/label/serpent (you'd have to scroll all the way down (END) and then click on the blue "no comments" link in the bottom to reveal the comments input form; a redirection to https://rtfreesoft.blogspot.com/2021/03/weekly-browser-binaries-20210313.html#comment-form takes place); or you can always include links in that blogspot banner to this thread or to the other forum(s) you provide support for your XP forks... We, as a community of users of your splendid offerings, just can't afford anymore to further aggravate Moonchild and Co. ... Thanks for reading, best wishes !

"Upstream" have just removed the years-long ability of official Pale Moon to accept Firefox-targeting "legacy" extensions: https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1748 UXP master branch https://repo.palemoon.org/MoonchildProductions/UXP/commit/3aa334d https://repo.palemoon.org/MoonchildProductions/UXP/commit/3064ad3 Pale Moon master branch https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/86e5b48 https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/bb6dab5 These changes haven't made it yet to the respective (UXP+PM) release branches, but I guess it's only a matter of time now... I think that route, which was already on the horizon for some time now, has been expedited considerably after the spat with (and following divorce from) ex-associate JustOff and his insistence on keeping Fx legacy extensions compatible with PM (via, among other things, CAA and MTT) ... 1. I sincerely hope/wish the above isn't even considered for inclusion by @roytam1, he's currently building NM28 with the --enable-phoenix-extensions mozconfig flag and they've axed it now... 2. MyPal follows closely the release branch and build configuration of official, release channel, Pale Moon, I'll be waiting with bated breath to see whether @feodor2 merges this in... 3. The code changes also touch platform (UXP) files, I hope Basilisk (and, thus, Serpent 52) aren't being harmfully affected by them, as St52 shares the same GUID with Firefox (and is natively able to load Fx extensions) ...

<OT> .... well, one related thread I did not manage to dig up in time... https://msfn.org/board/topic/181267-chromium-v-54-not-displaying-youtube-properly/ </OT>

<OT> Official link from author: http://browser.taokaizen.com/download/Advanced_Chrome_Windows_v54.20.6530.0.zip I'm out of breath in these forums saying that, in reality, Advanced Chrome v54 is NOT actually Chromium 54, but more of Chromium 48 under the hood... The percentage of Ch54 in it is quite small (just like Serpent 55 is actually, originally, a fork of Firefox 53.0a1, not Firefox 55.0!) ... Also, from https://browser.taokaizen.com/ 05 - Jan - 2018 .- Updated Custom Build to 54.20.6530.0 New on version 54.20.6530.0: Crash bug fix. Removed dynamic user agent, you can install Chrome UA Spoofer extension to change it. Not vulnerable versus Meltdown and Spectre. ... meaning that AdvChr54 advertises itself to YT as Ch54, not Ch48/49, and is thus being served incompatible polymers... I have an existing old installation of User-Agent Switcher for Chrome v1.1.0, by setting up a new custom UA of Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 naming it Chrome 49 [C49] and using that as a general UAO, yt then loads (after a wait of 10 - 20s, that is...) : However, if you haven't installed said extension in the past, you're just out of luck: Evil Google have recently (2021-01-19) re-uploaded it on CWS as a CRX3 only package, meaning it won't install now (you can try the archived file on https://www.crx4chrome.com/crx/515/ ). If the XP people want a current-ish Chromium engine, please use the Chinese-made, Russian re-packed, versions of 360 Extreme Explorer 11/12/13 (see relevant XP forum threads) ... </OT>

<OT> According to https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP SP3 Google Chrome 49 under fully updated XP SP3 should support the TLSv1.2 protocol, BUT with a limited number of cipher suites; supporting the protocol natively is one thing, but supporting ciphers to go with it is another ; Chrome 49 relies on OS crypto libraries for ciphers and the OS cert store for root certificates; XP doesn't support ECC suites and SNI, these two handicaps limit even more the amount of HTTPS sites that can be accessed... PS: Just compare the record of Ch49/XPSP3 (above) to Ch49/Win7 (below): https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=Win 7 </OT>