VistaLover

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>

I tried to reproduce with latest NM27 v27.10.0 (32-bit) (2021-03-05) here (Vista SP2 32-bit) and I couldn't; everything works fine in that regard ... Unless this bug is selectively targeting XP, in your case I would troubleshoot further by checking in a new pristine NM27 profile; chances are one of your installed extensions broke in builds past the 2020-11-28 one, manifesting the issue... <OT> Hint: ... all versions/flavours of Opera past v36 require Windows 7 SP1 and higher (portable v37 can also launch under Vista SP2, but not on XP SP3). Opera 36 is also based on a Chromium 49 core/engine; I hadn't launched my portable copy of Op36 in ages, but. by the looks of it, it manages to open/render Youtube fine: However, under XP, Opera (unlike Google Chrome 49) can't use patented decoders (h264, aka avc1, and aac), so only the other HTML5 codecs (vp8/vp9/opus/vorbis) can be used, possibly taxing resources and causing playback skips... </OT>

Also confirmed in latest Serpent 52.9.0 (2021-03-05) (32-bit) under Vista SP2 x86; a UA of Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Goanna/4.8 Firefox/52.0 Basilisk/52.9.0 will load/redirect to: https://www.opera.com/ie-simple while Mozilla/5.0 (Windows NT 6.3; rv:78.0) Gecko/20100101 Firefox/78.0 will load the full-blown, mobile design iteration of their homepage... (just https://www.opera.com/ ) The OS fragment of the UA is also at play here; with the first UA I get offered the XP/Vista EOL Opera version (36.0.2130.80 - offline installer) when I hit the "Download now" button, while with the second UA I'm offered an online (stub) installer of Opera 74.0.3911.203 (requires Win7+). Lastly, with Mozilla/5.0 (Windows NT 6.0; rv:78.0) Gecko/20100101 Firefox/78.0 I do load the full edition of the Opera homepage, but upon clicking the "Download now" button, I'm being redirected to https://www.opera.com/ie-simple and hence towards the offer of Opera 36 ... OT: Opera 36.0.2130.80 dates back to August 2016 (!); is anyone among you (still) using it? And if yes, how does it cope with the 2021 web (the one Google single-handedly have created) ?

Hi @Vistapocalypse , sure hope you're OK under these perilous times... I'm kinda lazy now to dig up my portable copy of YB 17.4 (Chromium 57 based), so I'll assume that whatever is true for portable YB 17.6 (Chromium 58 based; launches on Vista SP2 but NOT on XP SP3) stands also true for the former... One must disregard the blatant banners and incompatibility messages displayed when visiting the OWS with YB 17.x; according to https://forums.opera.com/post/208773 ... it is probable that versions of YB > 20.3.1.197 won't install Opera extensions anymore; but this is certainly not the case for YB 17.6! Just persevere with the "Install Extension" button and Bob's your uncle: I hope those pics dispel whatever latent doubts...

... And the rift between @JustOff and his ex-associates within MCP grows wider and wider... ; the screengrab below is from NM27's add-ons manager (AOM): Thank you JustOff for standing up against authoritarian oppression...

Which version of Yandex Browser is this happening on? The XP/Vista compatible version (17.4.1.1026) is not able anymore to install newer signed Chrome extensions (.crx files) from the CWS or elsewhere, because, since last May 2020, those are only being packaged in the newer format CRX3, which requires a more recent (to 57) Chromium core... YB 17.4 only supports the older CRX2 format, so in a new profile you can only install compatible extensions which were last updated before May 2020 - in an existing profile, previously installed extensions won't auto-update to a new version, if that has been released after May 2020; also, be careful not to inadvertently uninstall existing extension(s), CWS (unlike AMO) doesn't keep older versions of extensions, thus you may find yourself in a position of not being able to re-install said extension(s) ... YB has native support for Opera extensions, so you may try installing uBlock Origin from the Opera Web Store: https://addons.opera.com/en/extensions/details/ublock/ BTW, YB comes already bundled with its own content blocker, AdGuard Adblocker, the last version compatible with 17.4 is 3.5.23 ... PS: There's enough info on-line covering the differences between CRX2-CRX3 packaging formats, just use your favourite search engine...

Did you take care to also restart the machine between uninstallation of 14.28.29812.0 and installation of 14.28.29213.0 ? Firefox specifically comes with a dependentlibs.list file inside its main appDir, whose content reads: MSVCP140.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-convert-l1-1-0.dll VCRUNTIME140.dll api-ms-win-crt-math-l1-1-0.dll api-ms-win-crt-filesystem-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll mozglue.dll api-ms-win-crt-utility-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll api-ms-win-crt-multibyte-l1-1-0.dll nss3.dll lgpllibs.dll api-ms-win-crt-locale-l1-1-0.dll xul.dll So, firefox.exe is instructed to forcibly look for these DLLs (12 api-ms-win-crt-*.dll that are part of Windows 10 Universal C Runtime, 2 that are part of VC++2015-2019, 4 that are part of Firefox itself) only there, not in system directories... If you remove just the Win10UCRT dlls without also removing them from inside dependentlibs.list, then you'll get the "Can't load XPCOM" launch error... For Vista SP2 and higher, we have KB2999226 (Win10UCRT), so if I modify dependentlibs.list to MSVCP140.dll VCRUNTIME140.dll mozglue.dll nss3.dll lgpllibs.dll xul.dll ... I can launch Firefox without any api-* DLLs present adjacent to it (they are loaded from within system32); likewise, trimming down dependentlibs.list to just: mozglue.dll nss3.dll lgpllibs.dll xul.dll will force firefox.exe to look for dependent DLLs (Win10UCRT + VC++) in the system dirs, if they're absent in appDir; if you don't have them installed either, then you'll get the following launch error: Because KB2999226 doesn't exist for XP, VC_redist.x86.exe does bundle/install these Win10UCRT DLLs under XP... Are things any clearer now?

... Does that test imply first deleting the copies of MSVCP140.dll & VCRUNTIME140.dll (v14.0.24210.0) that were originally shipped with FxESR 52? Yes: https://docs.microsoft.com/en-us/windows/win32/api/threadpoolapiset/nf-threadpoolapiset-closethreadpoolwork#requirements

... Yes, this fact was posted already on Feb 6th by @George King , so nothing revolutionary here (no disrespect meant) ... As you belatedly found out, I posted these already on Feb 6th, but I guess having the last post on a thread's page is a safe bet others will miss noticing it... OT, of course, for this thread, but 14.28.29812.0 installs and runs perfectly fine under Vista SP2 32-bit (CPython 3.7.10 x86 launches fine with it, doesn't launch without it! ) Kind regards

@Sampei.Nihirahas only been using New Moon 28; in his reply, he's not saying anything about Serpent 52; once again, the usual confusion between platform (UXP) and applications (NM28 vs St52) built on top of that same platform (i.e., the common platform does not exclude the existence of differences between the applications...) ... A simple test in Firefox ESR 52.9.1 reveals that privacy.firstparty.isolate;false indeed exists already in it, so it's no wonder it's there too in its direct descendant, Serpent 52.9.0 ... A cursory search in Bugzilla reveals that the pref itself was first implemented as part of #1260931 : [Bug 1260931 - Part 2: add pref privacy.firstparty.isolate] https://hg.mozilla.org/mozilla-central/rev/d173cefba1e1 in Firefox 51.0a1; but to give credit to Sampei , the feature behind that pref seems to have matured in Fx 55.0 stable, and this is where many Google search results agree on: https://www.bleepingcomputer.com/news/software/another-tor-browser-feature-makes-it-into-firefox-first-party-isolation/ https://www.ghacks.net/2017/11/22/how-to-enable-first-party-isolation-in-firefox/ TL;DR privacy.firstparty.isolate does not exist in NM28, but does exist in St52 (default=false); toggling that pref in St52 (to true) presents risks that (some) sites may break, because First Party Isolation in FxESR 52 was in its infancy development-wise... Addendum: privacy.userContext.ui.enabled likewise is absent in NM28, but present in St52; I'll leave it as an exercise to the reader to track down when that pref was first introduced in Firefox (and thus ended up in St52) ... Hint: it's related to Container Tabs, a feature originally present in FxESR 52 and official Basilisk 52, which the MCP devs later decided to scrap ; due to demand by members here, again expressed more loudly by MIA @Mathwiz , that feature still survives in Serpent 52.9.0...

Pale Moon as an application had never incorporated any WE support whatsoever, and that was, of course, true for v27, which was Tycho (Mozilla ESR 38 fork) based; when MCP "transplanted" the Pale Moon application onto their new UXP platform (Mozilla ESR 52 fork) and upgraded its major version from 27 to 28 (and, recently, to 29), no provision was made to equip it with any means of accessing the WE code then present in the new platform; Pale Moon shall forever stay free of the Web Extension "pollution"... In its initial days, Basilisk was touted as the browser non-Quantum Fx migrants should choose, because, unlike Pale Moon, it supported both "legacy" and WE addons, plus it had EME (WidevineCDM) support; where are we now? WE support removed, EME support broken, soon to be completely excised... IOW, Basilisk is practically Pale Moon wearing the Australis interface (oversimplified, differences do exist...).

The original Basilisk 52 project from "upstream" did have WE support, be it somewhat inferior to the one present in the Mozilla 52.6.0 platform they forked off as UXP; the MCP devs disabled/removed some WE features/APIs initially, e.g. id-less WEs were not supported, because Basilisk 52 does not observe extension-signing... Having partial WE support in their test UXP browser application (Basilisk) was something the MCP people felt quite uneasy about, given their lack of any will to further maintain that part of the platform code; coupled with their general disdain/aversion for WE (a Google Chrome spawned and Firefox-aped technology), they finally removed completely all traces of WE support in Basilisk 52 in February 2019 (Basilisk-52.9.2018.12.18 the last with WE support, Basilisk-52.9.2019.02.11 the first with no WE support). After consultation with members here (where are you @Mathwiz ? ) it was decided that Serpent 52 will continue to contain that (partial) WE support in an "unmaintained/use at your own risk" state ; WE related security issues are not being patched by upstream/our current maintainer; if you install from AMO, be warned that many (WE) addons there are marked in a blanket fashion as "working in Fx 48.0 and higher", but often times this is simply not true, because WEs of today are NOT being tested on Fx 48-52 ; additionally, Serpent 52 does not check AMO for WE updates, so that is left upon you (i.e. bookmark a WE addon's page on AMO and visit occasionally for eventual updates); be weary of WE updates, in many cases the updated addon uses WE APIs not present in St52... I personally use several WEs in St52, e.g. the userscript manager Violentmonkey 2.12.9 and userstyle manager Stylus 1.4.23