VistaLover

Undoubtedly a typo , should've been 2.40.0 and 2.13.2, respectively ; best regards ...

@AstroSkipper (all links produced via a Forum Search, BTW ) : Two ways to tackle this: 1. In "about:config", toggle "dom.abortController.enabled" to false, restart Serpent 52 and then installing the userscript from that GH page will work (just tested it now ); but the abort API is still needed by GitHub to properly function, so, after installing the userscript, reset the pref and, again, restart St52... 2. "Patch" the actual extension in below fashion: "./background/index.js" (a minified JS file): -!(!e.AbortSignal||!browser.windows) +(!!e.AbortSignal&&!browser.windows) Again, VM-2.14.0 works as expected in actual FxESR 52.9.x (it doesn't have itself the abort API), the breakage in St52 is due to MCP's (imperfect) abort API implementation inside UXP (FTR, VM's devs are almost oblivious to St52's existence ...).

Noted, and I trust your knowledge/expertise ... Thanks again !

If members here running St52 and/or NM28 wish to be served the "current" iteration of Google Search (the one targeting latest browsers), a SSUAO is necessary; in latest NM28 with its default UA: OTOH, with: general.useragent.override.google.com;Mozilla/5.0 (%OS_SLICE% rv:55.0) Gecko/20100101 Firefox/55.0 Fine-tuning the appearance of GS is possible via its settings (cogwheel button) ; as seen, I've opted for its dark theme ; caveat: the modern GUI is more resource-hungry ...

... Those (few ) of you that like to occasionally browse the Official PM Forums for info/troubleshooting related to UXP-based browsers discussed here (encompassing St52, NM28 and a few others), "their" breakage seems to persist; latest news from MC himself (via the temp Discord server): So, Wednesday (today) won't be "restoration day" ...

For starters, Roy's blog, https://rtfreesoft.blogspot.com/search/label/browser would be the first to become inaccessible from within HK, since "blogger" is a Google-provided service ... Although a pessimist by nature, I still hope/wish that things won't reach any extreme levels... If GitHub and MSFN remain accessible from within HK, then, perhaps, a move to an overseas server hosting the binaries would be all that's needed; determined people in mainland China have come up with inventive solutions able to penetrate through the GFW, however these "solutions" might be against local laws; i.e., I'm not suggesting myself Roy should break HK legislation, if/when enforced...

Many thanks for your code! ; I adapted it for Violentmonkey installed in St52 (can also be used in St55, I guess ), here's how the "==UserScript==" header looks there: // ==UserScript== // @name Fix <link rel="preload" ...> in MS Support site // @version 0.1 // @author UCyborg // @namespace UCyborg // @description Fixes CSS rendering on "support.microsoft.com", on UXP-based browsers // @homepageURL https://msfn.org/board/topic/184051-my-browser-builds-part-4/?do=findComment&comment=1246726 // @icon https://support.microsoft.com/favicon-32x32.png // @include https://support.microsoft.com/* // @run-at document-start // @grant none // ==/UserScript== Here it is enabled inside VM itself: ... Microsoft are currently focusing solely on their offspring browser (ChrEdge) they conceived after fornicating with their former opponent, Google ; one (perhaps more ?) MS coder authored code that was tested to work on ChrEdge (perhaps also tested in latest Fx), with no care in the world for "legacy" browser engines ; but it was Google that started this in the first place: ... Should be back up on Wednesday (fingers crossed):

Thanks ; works as advertised in my 32-bit OS: [debug] Command-line config: ['--ffmpeg-location', '..\\FFmpeg', '--downloader-args', 'ffmpeg:-v 8 -stats', '-v'] [debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out cp1253 (No VT), error cp1253 (No VT), screen cp1253 (No VT) [debug] yt-dlp version nightly@2023.06.13 [cab94a0cd] (win_x86_exe) [debug] Python 3.9.13 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev ) [debug] exe versions: ffmpeg n6.1-dev-1149-N-111033-gf11515c (setts), ffprobe n6.1-dev-1149-N-111033-gf11515c, phantomjs 2.1.1, rtmpdump 2.4 [debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.05.07, mutagen-1.46.0, sqlite3-2.6.0, websockets-11.0.3 [debug] Proxy map: {} [debug] Loaded 1843 extractors Usage: yt-dlp_x86 [OPTIONS] URL [URL...] yt-dlp_x86: error: You must provide at least one URL. Type yt-dlp --help to see a list of all options.

... Well, this thread contains mixed content about both youtube-dl (in the topic's title ) and yt-dlp, and is primarily a WinXP one (), so the info I post below might be considered as only remotely relevant, especially since nicolaasjan already provides py3.8-based XP[+Vista]-compatible yt-dlp (32-bit) compiles, still ... June 5[6]th saw the release of Python 3.7.17 by the PSF, a source-only security bugfix release: https://www.python.org/downloads/release/python-3717/ https://docs.python.org/release/3.7.17/whatsnew/changelog.html#changelog Windows binaries (Vista SP2+, x86 & x64) are being provided by a third party and can be found here ; Python 3.7, according to PSF's official lifecycle policy, will receive security fixes i.e. current month () ; https://www.python.org/downloads/ specifies the py3.7 EoL date as 2023-06-27, in ca. 2-weeks time ; we may see one final py3.7 update in the form of v3.7.18 towards the end of this month, but I personally doubt that, as 3.7.17 has been released just a week ago ... I guess the ball is now on yt-dlp's court, to start considering removing support for py3.7, eventually... py3.7 is currently being used to compile the yt-dlp_x86.exe builds for Vista SP2 (both 32 & 64-bit) and for the 32-bit minorities on Win7 SP1, Win8, Win8.1 and Win10 (Win11 doesn't come in a 32-bit flavour); py3.8 is currently being used to compile yt-dlp.exe (64-bit) for Win7 SP1+ x64 users (the masses, I guess ...); many devs inside the yt-dlp team have expressed in the past their desire to forego completely py3.7 and py3.8 support at the same time, switching directly to py3.9+ (or, perhaps, py3.10+), especially since Win7 usage is dwindling over the last months (not least because evil Google dropped support for the OS); that leaves the question pending over the fate of the yt-dlp_x86.exe binary itself, as the trend now among app authors is to switch exclusively to 64-bit ; I'll sure be keeping an eye over at the yt-dlp repo for any related (ill-)developments ...

The "fix" has now reached youtube-dl master branch: [jsinterp] Fix div bug breaking player 8c7583ff

With previous-to-latest Serpent v52.9.0 (2023-05-25) (32-bit), on a SSE2-capable Vista SP2 32-bit host, Web Console is more "verbose" : Most sadly, it appears marktplaats.nl have recently implemented another Chrome-ism (), BigInt: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt This JS feature was first introduced in Google Chrome 67 (later portions of it in Chr76) and in Firefox 68 (with later portions in Fx70); there's a currently open UXP issue about it, https://repo.palemoon.org/MoonchildProductions/UXP/issues/1240 (first opened 4[!] years ago), that is seeing some recent activity undertaken by the UXP MacOS developer, dbsoft, but, unfortunately, nothing concrete has come out of it as yet ... So, for now, "BigInt" is another UXP killer ... Commiserations @Reino ...

In NM28 (32-bit) buildID=20230310122857, I toggled layout.css.report_errors (to true), then loaded: https://www.lner.co.uk/ and witnessed it not rendering properly (and that particular site was also mentioned in these forums in the past, but somewhere inside the 360EE subforums... ); opening Web Developer Tools => Web Console, I see it's flooded with below (CSS) warnings: Missing closing ‘)’ in negation pseudo-class ‘,’. Ruleset ignored due to bad selector in: https://d13w9pwhlf25to.cloudfront.net/dist/css/homepage.css?v=638199212840000000&cdnv=2727 Searching for that warning, the second entry Google returns is: https://github.com/less/less.js/issues/3021 i.e. the site in question uses a CSS selectors Level 4 feature (), ":not()" with a selector list, first implemented in Fx84 and Chr88 (hence the site doesn't render in any 360EE version ): https://caniuse.com/css-not-sel-list More about that feature below: https://developer.mozilla.org/en-US/docs/Web/CSS/:not Returning to the changelog between working & non-working NM28 builds, I'd say it's UXP #2137 : Modify :not() selector to accept a complex selector list - Issue #2137 - Part 1: Modify :not() selector to accept a complex selector list (82fa9fb80) - Issue #2137 - Part 2: Implement SelectorParsingFlags and use it to pass info around (3bb3c193d) - Issue #2137 - Part 3: Don't always use the internal pseudo-class for handling negations (b257a71cc) - Issue #2137 - Part 4: Fix namespace regression (ef36c5659) I hope this answers satisfactorily your original query ...

Thanks for your prompt reply and further actions ; it is rather unfortunate that "youtube-dl.exe", in contrast to "yt-dlp_x86.exe", doesn't provide any indication at all, when invoked in verbose ([debug]) mode, of the code snapshot it's been built from ... ... If I'm counting right , on top of yt-dl's master branch, your yt-dl compiles also include PRs #29318, #29581, #29593, #30998 , plus enabling of Lazy Extractors; am I missing anything else? ... Not system wide, i.e. in %PATH%; I usually place ffmpeg.exe+ffprobe.exe adjacent to youtube-dl.exe or specify their specific directory via the " --ffmpeg-location" command line (or config) option: [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['--ffmpeg-location', '.\\FFmpeg', '--external-downloader-args', '-v 8 -stats', '-v'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2023.05.25.19419 (single file build) [debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015 [debug] exe versions: ffmpeg n6.1-dev-804-N-110688-g1aeefc4, ffprobe n6.1-dev-804-N-110688-g1aeefc4, phantomjs 2.1.1, rtmpdump 2.4 [debug] Proxy map: {} Usage: youtube-dl [OPTIONS] URL [URL...]

Hi @nicolaasjan, I do hope you're well - RL issues prevent me from visiting MSFN as often as I used to ... Might I inquire what exact source code is your latest youtube-dl.exe offering (linked in your forum signature) built on? The binary's version states May 21st: youtube-dl -v => [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['-v'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2023.05.21 [debug] Lazy loading extractors enabled [debug] Python 3.4.4 (CPython 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 1.0.2d 9 Jul 2015, -) [debug] exe versions: none [debug] Proxy map: {} Usage: youtube-dl [OPTIONS] URL [URL...] youtube-dl: error: You must provide at least one URL. Type youtube-dl --help to see a list of all options. ... whereas yt-dl's master repo is currently at commit d1c6c5c from May 11th ... Many thanks for any insight ...

... Just a small FYI: St52 (unlike official Basilisk) has kept Fx52-level WebExtension support, so a WE Mozilla "theme" (a "persona" in WE format) will actually install (and appear inside "Extensions", not "Themes"), but will not visually apply...

TL;DR: a) Roll back to a previous firmware, b) use a Chromium-based browser to access your Fritz!Box's GUI, c) change your router's model... https://forum.palemoon.org/viewtopic.php?f=70&t=28995 https://github.com/martok/palefill/issues/83

Apologies I'm not participating in this discussion as much as I would've hoped ; dealing with solicitors/lawyers/civil servants/government employees/etc. over inheritance issues in RL currently, all that "torture" sucks the life (and serious money) out of you and, consequently, spare time to devote on internet forums... In the background, I've been doing my own research, too ... ... Oh yes, the drawbacks of on-line/web installers and the very reason I detest them vehemently ; they become worthless when the stuff they're supposed to fetch vanishes into thin (digital) air ... I have several archived KFA19 web installers on a spare external HDD that were downloaded at the time the app was current (mid-2018 to mid-2019), which correspond to different localisations/Kaspersky patch levels (e.g [a.b], [a.b.c.d]); download links for these I now simply lost or (the ones I have bookmarked) return 404s... Kaspersky did publish a FULL offline installer (which, sadly, I haven't archived) for KFA2019 around its initial release, but soon they moved on to a web-installer-only scheme, a practice still kept for the subsequent KFA releases (kfa20, kfa21, targeting Win7SP1+; these two seem to have been remodeled, based on a newer "Cloud" engine/product: Kaspersky Security Cloud, KSC). Of those stub KFA2019 installers, one (kfa19.0.0.1088ab_en-gb_14833.exe) produced below message: I guess the same one @mina7601 encountered ... But another one (kfa19.0.0.1088abcd_en-US_fr-CA_es-US.exe) ended up with a different message: however, that was a misleading error ; unable to retrieve the now missing files for KFA19, it proceeded to download a web installer of KFA20 (v20.0.14.1085.0.6449.0), which, when executed, threw the error about the incompatible OS - all this was found out via inspecting the log file generated inside %TEMP% ... A third stub installer (kfa19.0.0.1088a_en-gb_14166.exe) produced, yet again, a different error: In that last case (resolved by inspecting log files), the stub installer proceeded to fetch a second stub installer of KFA21 (v21.3.10.391.0.2008) which, predictably, failed to install.. My research has also unearthed a 2018 malwaretips post, in which it was documented that the KFA2019 web installers of the era (for en-GB locale) would actually download below list of files/archives: KFA 2019: http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/corebases.cab http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/corebasesx64.cab http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/corebasesx86.cab http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/instx64.z http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/instx86.z http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/productbases.cab http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/common.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/coreproductnogdpr.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/coreproductgdpr.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/coreproduct.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/coreproductx64.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/eula_en-gb.txt http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/ipm.cab http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/ksde_ksn_en-gb.txt http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/product.cab.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/product.msi.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/rdp_en-gb.txt http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/startup.exe http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/x64.cab.z http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/ztuu.z http://dm.kaspersky-labs.com/kleaner/InteractiveNew/Global/kleaner.cab The "http://dm.kaspersky-labs.com/bases/kavkis2019/KIS/*" dir appears to be still alive today, as well as access to last archive kleaner.cab, but, as already posted by others, dir "http://dm.kaspersky-labs.com/en-GB/KFA/19.0.0.1088/*" has been now purged ... Some savvy people had concocted self-made "full" (off-line) installers at the time, based on lists similar to the above; I myself have an archived "RePack" which I won't share, because it's only in the Russian locale and made by, well, a Russian repacker (LcHNextGen) of that era... I haven't yet tested Astroskipper's repacked RePack (), hopefully we'll soon hear results from mina7601 (many thanks BTW ) ... It might not be the case after all ... During my research, I found some posts inside the nsaneforums forum (due to the "dubious" nature of said site, I won't provide exact links), an installation scenario might involve the following procedure: 1. Download the off-line installer for KIS2019 (Kaspersky Internet Security): https://arc-products.s.kaspersky-labs.com/homeuser/kis2019/19.0.0.1088abcd/english-INT-0.5887.0/3137353438307c44454c7c35/KIS19.0.0.1088_en_full.exe 2. Install the application as required (decline any offers to install newer versions; no other AV suite should be present, all H/W and S/W requirements for KIS2019 should have been observed/applied). 3. After the necessary OS restarts post initial install, try (for good measure) to update the Virus Definitions - you can only do so once without a valid licence; the app may or may not be activated now with a trial (30d) licence, this is at Kaspersky's discretion - if you do get a trial licence, you may continue to use the product fully until the trial ends - else (or after the trial expires): 4. Proceed to uninstall the application; if my "sources" were correct, one of the options offered during uninstall is to "turn the application into Kaspersky Free 2019"; if you select that, upon OS restart you'll end up with a KFA2019 installation; if you don't now have a 365d worth "free" key, you should first create a "My Kaspersky Account" to then get one (YMMV - my sources are from 2019 ) ...

... Thanks for that kind offer ; unfortunately, my memory betrays me these days. ... I've managed to locate a certain post by @Vistapocalypse where he, in fact, makes a mention of what I've spoken about, however I was not successful at locating those exact reports... Kaspersky themselves no longer offer downloads for KFA2019 (Kaspersky Free Antivirus 2019, aka Kaspersky Antivirus Free (KAF) 2019 or just 19), but "neowin" have archived a stub (web/on-line) installer for it: https://products.s.kaspersky-labs.com/homeuser/kfa2019/19.0.0.1088/english-gb-0.57.0/kfa19.0.0.1088en_14173.exe Since mina7601 keeps a Vista SP2 VM, perhaps an attempt to install it there could be made? For best results, that VM should be first updated all the way to Vista's EoL, plus select WS2008 updates enabling SHA-2 signature support should also be installed; additionally, KFA2019 requires .NET FW 4.x.x installed; for NT6.0, Microsoft have last year produced a 4.6.2 installer that works out-of-the-box (whereas in the past, only 4.6.1 would work) ... All this talk is, of course, OT for this (XP) thread , but since an offer was made to clarify things once and for all, why not accept it? Perhaps even attempt an installation of KFA19 on a fully updated XP SP3 system (with .NET FW 4.0.3) while one's at it?

... Well, according to below support article, last reviewed on Aug 13, 2019, min WinOS version targeting KAV19 is Windows 7 Starter SP0 : https://support.kaspersky.com/KAV/2019/en-US/43520.htm It's totally unknown to me whether KAV19 could be installed on Vista SP2 (let alone on XP SP3) 32-bit, provided all the rest software/hardware requirements were met (and there were several ) ; still, I have a very faint recollection of someone posting back then in the Vista subforums, claiming to be running KAF19 (Kaspersky Antivirus Free 19) under Vista (but NOT XP!), but am too tired now to search for that post, sorry ...

Indeed, the provided link: https://dl.dropboxusercontent.com/s/77c6ftwujel4v7l/yt-dlp_x86_Windows-XP.zip isn't valid ; obviously, something must've gone awry there... Try below links, which I have archived locally (and it turns out it was a good idea to do so ): https://dl.dropboxusercontent.com/s/f2q5v92qgq0fawp/youtube-dl.zip https://dl.dropboxusercontent.com/s/xmrpypozf7wf9us/youtube-dl_20230430.zip The second link will fetch a yt-dl build with (experimental) "Lazy Extractors" support turned ON, specifically for older H/W; you should definitely try it (both links were provided initially by nicolaas, the second one via his GitHub account) !

... People ... Do you know the Bible quote: "seek, and ye shall find" ? With some perseverance (which always pays out, mind you ) and my mediocre searchengine-fu, it took me less than 10min to locate an official (by AVG) direct download link to the XP_EoS offline installer of AVG Free Antivirus product: https://install.avcdn.net/avg/iavs9x-xp/avg_antivirus_free_setup_offline.exe This fetches a 292MiB sized file, which has been dual-signed (sha1 file sig compatible with XP and sha256 sig compatible with Vista/WS2008 SP2 and later) on Nov 15th 2018:

... Well, "Dwm" stands for Desktop Window Manager, and that one is only present on Vista+...

Thanks for your investigation ; https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields#browser_compatibility says that this JS syntax feature has been implemented in Chr72+/Fx69+ (so, a long time ago ); "upstream" now have an open UXP issue about it, opened just 2 months ago by @martok (the maintainer of palefill): https://repo.palemoon.org/MoonchildProductions/UXP/issues/2142 This is being worked on currently, so, fingers crossed, "we" may see a positive outcome/resolution soon-ish ... Slightly OT: I was puzzled by the fact my 360EEv11 copy, Chr69-based, was able to display images inside https://www.winhelponline.com/blog/disable-full-row-select-explorer-windows-7/ since the "feature" was only implemented as of Chr72, but then I realised I had, since long ago, enabled the "Experimental JavaScript" flag in that build (chrome://flags/#enable-javascript-harmony); mystery solved, as that flag enables a "draft" version of public class fields already in Chr69!

... Still, someone on XP will have to verify whether v7.4.2 does launch there (and was hoping you'd be the one ...) ; and just because it did download the 2022-10-10.1 (cloud) database in my Vista SP2 32-bit machine, it doesn't necessarily mean it will do so under XP; AFAICT, the app uses Windows' native APIs to connect to its (cloud) server; my Vista OS has WS2008 updates installed, which gave it TLS v1.1+v1.2 support, plus associated cipher suites that are not present even in a POSReady updated XP machine... As always, "the proof is in the pudding" ...

This article below by MB: https://support.malwarebytes.com/hc/en-us/articles/360039579393-Windows-XP-and-Vista-compatibility-with-Malwarebytes-AdwCleaner hints that "Versions before 8.0 may still work on a Windows XP", emphasis (mine ) put on "may"... FWIW, I have local records kept that indicate that the XP_EoS version of Malwarebytes AdwCleaner is/was v6.047 : There doesn't exist a GUI button to update the "database", only an "option" to use the "local" or the "server" one: I did perform a quick scan with the default setting of "server"; I had to open the log file to, sadly, find out that only the extremely outdated "local" database was used for the scan: # AdwCleaner v6.047 - Logfile created 26/04/2023 at 00:25:03 # Updated on 19/05/2017 by Malwarebytes # Database : 2017-05-19.1 [Local] # Operating System : Windows Vista (TM) Home Premium Service Pack 2 (X86) # Username : (redacted) # Running from : (redacted)\adwcleaner_6.047[XPEOL].exe # Mode: Scan # Support : https://www.malwarebytes.com/support I don't have an XP machine available currently to check whether v7.4.2 does, indeed, launch there ; that version does launch under Vista SP2 x86 - incidentally, it offers to update the app to v8.4.0, but that offer should be declined, as (consistent with the article I linked above) that one doesn't launch under Vista (so why offer it in the first place? ) ... Like its predecessor, v7.4.2 has a default setting of "Automatically using the cloud database if available": I performed a second scan with v7.4.2, its log file now reads that it used a "database" from Oct 10th 2022, i.e. a stale one from 6 1/2 months ago (!) : # ------------------------------- # Malwarebytes AdwCleaner 7.4.2.0 # ------------------------------- # Build: 10-21-2019 # Database: 2022-10-10.1 (Cloud) # Support: https://www.malwarebytes.com/support # # ------------------------------- # Mode: Scan # ------------------------------- # Start: 04-26-2023 # Duration: 00:00:35 # OS: Windows Vista (TM) Home Premium # Scanned: 32074 So, I don't know what to make of that , certainly can't answer whether that is considered as "definitions still provided for it" ; "use at your own risk" would be my advice ...