VistaLover

... It would appear "someone" is reading this thread ; disregard above link (it now 404s), here's the new one: https://github.com/3dyd/pyinstaller-builds/releases/tag/latest (with previous releases (6.16.0) reinstated )

New 6.17.0 releases by 3dyd (and it's a shame every new release overwrites the previous one ; not a good practice if "things" break and one needs to revert ) : https://3dyd.github.io/pyinstaller-builds/

... Well, this isn't a very reassuring answer, you do realise that ... Don't know ; perhaps @user57 is on the right track on this (or even @cmalex, safe may he be, knows more ); the question to be asked is why did it magically appear in the latest yt-dlp WinXP compiles, whereas it wasn't present (needed?) all that time before? ... Can't tell; my AV solution gave it a "clean bill of health" ; you can try to see if the WinXP packages launch and function OK WITHOUT it, then take the necessary steps to remove it altogether; I'm not being paranoid (I think ), but I'd rather not have it there, if it isn't indispensable... Best festive wishes ...

Another thing I wanted to mention to you @nicolaasjan is that in both the latest "WinXP" packages: https://github.com/nicolaasjan/yt-dlp/releases/download/2025.11.25.144622/yt-dlp_x86_winXP.exe https://github.com/nicolaasjan/yt-dlp/releases/download/2025.11.25.144622/yt-dlp_x86_winXP.zip a new DLL appears to have infiltrated, "fileextd.dll", which wasn't there in all of your previous "WinXP" releases, e.g. in https://github.com/nicolaasjan/yt-dlp/releases/download/2025.11.12.051143/yt-dlp_x86_winXP.exe https://github.com/nicolaasjan/yt-dlp/releases/download/2025.11.12.051143/yt-dlp_x86_winXP.zip Was that an inadvertent inclusion?

Ditto that...

Makes sense; if Z was the last to have been loaded in the tab when that tab was closed, why do you expect otherwise? After all, the browser feature is called "Recently Closed Tabs", not "Recently Visited Sites" ; however, a closed-tab's history isn't being deleted (it's saved in session data); re-open the tab with site Z on it, then use the back button once to revisit site Y (or twice for site X, etc.) ...

@nicolaasjan: Sunday is Nov 30th, 2025, thus I believe you'll be having a "hot potato" in your hands : https://github.com/pyinstaller/pyinstaller/issues/9149#issuecomment-3036991021 [build] Bump PyInstaller minimum version requirement to 6.17.0 https://github.com/yt-dlp/yt-dlp/commit/280165026886a1f1614ab527c34c66d71faa5d69 For the Vista+(aka Win7) builds, your PyInstaller fork v6.17 came just in time : https://github.com/nicolaasjan/pyinstaller-builds/releases/tag/6.17.0 ... but what about those WinXP "onedir" packages which, IIANM, are still using PyInstaller-5.13.2 due to this ? (you can always revert 2801650 prior to the onedir compilation for XP, but how practical would that be in the long run? ...)

Totally understandable; sincere condolences for the loss of life of so many of your compatriots ...

Thank you a bunch for spoiling us ... The new shared build runs OK here (Vista SP2 32-bit) ; compared to the previous Vista+ shared offering (ffmpeg-n8.1-dev-891-git-20251025-gdefd5f3), I see that below libs (rather, buildconfig flags) have been removed: --enable-cuda --enable-cuvid --enable-d3d12va --enable-nvenc --enable-ffnvcodec --enable-nvdec --enable-mediafoundation --enable-libvpx --enable-libaom --enable-librav1e --enable-libkvazaar --enable-libxavs --enable-vulkan --enable-libvvenc --enable-libcelt --enable-opencl This has reduced the size of the extracted archive by ca. 23 MiB (from 127 to just 104); really indebted! Best wishes.

I wasn't aware ; if that is the case, shouldn't this forum glitch be posted in https://msfn.org/board/forum/23-site-amp-forum-issues/ ? (Or is one now completely unable to?) Are any of the admins/mods made aware? At what exact stage does the "new topic" fail to be submitted? FWIW, the "Create New Topic" button seems to work OK here, but I haven't proceeded in actually submitting one ... @Dave-H, do you happen to have any insight on this?

... I think you've hit issue #185 , which the Chrome++ author (Bush2021) closed as "wontfix/not planned" ... Yes, I also believe "change/update" isn't always for the best , but what can one do ...

Which r3dfoxESR 140? NB, 140.5.0esr has been LibreWolf-ified (read above), while previous ESR, 140.2.0, has NOT... That one, too, is LibreWolf-free ... Hard to tell these days ... Since I always use the "portable" r3dfox variants (the browser profile is created inside a "Profile" dir adjacent to (r3dfox | r3dfox_esr).exe), I couldn't possibly have noticed your findings ; based on your findings, though, this is how I would migrate from r3dfox-139 to r3dfox-140esr: 1. Launch 140esr a first time and let it write/populate its default fresh profile in the "new" location (in "%AppData%\Eclipse Community\R3dfox ESR" ?) ; 2. I suppose you've already done this, but with 140esr open, load "about:support" => Profile folder (where you can see the absolute path to the ESR profile) => Open Folder 3. Exit r3dfox-140esr; then, erase all contents of the fresh ESR profile (already open in an Explorer window in step 2, above) 4. Inside the (now empty) 140esr profile folder, transfer/place all contents of your r3dfox-139 (release) profile (NOT the profile dir itself, just what it contains); 5. Launch 140esr anew; it SHOULD now load what was previously your r3dfox-139 profile... (Disclaimer: I haven't actually performed such a profile migration myself, my "guide" is based on educated guesses )

You are right, of course, but that "exact and precise finite control of these associations" is in practice left for "advanced" users, not "average" Windows user "Joe" (at least that's how I see it myself ) ... Like you, I was introduced to the PA.com format many years ago, and, actually, after an "accident" that happened during my WinXP era, when sister ran a "wipe whole C drive" virus on then "family" desktop; after a Windows reinstall (no C drive back-ups were being taken at that time ), I had to reconfigure all re-installed programs from scratch... PA.com format appealed to me, because I could "install" many programs on a second, D, disk partition, where both the applications' binaries and their settings would reside; in the unfortunate event of a second C partition "demise", all my "portable" programs on D partition would survive... I think most take "portable" to signify "have the app's settings alongside the app's main (binary) files, not save settings in %appdata% and/or the registry"; but "portable" also means "be able to store the app and its settings/configuration to a suitable external storage medium (USB stick, ExtHDD/SSD, etc.) and be able to transfer the storage device and use said "portable" app across many different hosts, without permanently impacting (and/or leaving traces in) each host's fie system/registry/etc. ; this is why most portable app authors advise not to establish associations of any kind with the host system the portable app is currently running on; yes, I've come across very "smart" portable launchers that clean up the host system after the app has been exited, but that depends on the exact launcher; during the years, I have seen portable-application users associating portable launchers with the host system, and this has less risk overall, but, TBH, I don't do that myself either... Now I'm thinking of it, my advice "not to associate" was particular to the simple "Sm-Portable.cmd" batch file I posted previously ; this isn't a proper "portable launcher" per se, so if you clicked on a URL link inside a PDF file and expected that to be opened in the "portable" Supermium "Profile", then I couldn't offer an "easy" way to do that (you'd probably have to mess with the registry, and so on) ; and the "--disable-encryption --disable-machine-id" switches were specifically added so that the portable "Profile" remains unlocked and accessible/readable across hosts ...

IIRC, the "nonsetup" zip versions were created for "special" cases (namely WinXP machines without all SPs and/or partially updated), where the provided ".exe" installers wouldn't run; FTR, the first "*_nonsetup.zip" release asset saw the light of day with the 124-r4 release: https://github.com/win32ss/supermium/releases/tag/v126-r4 As posted by NHTPG, these are NOT "portable" packages; Supermium "portable" packages were once offered as part of a paid for Patreon subscription: https://www.patreon.com/posts/supermium-122-r2-103469536 If you don't mind the registry being written to, a simplistic "portable" approach would be to write a "Sm-Portable.cmd" batch file: place it adjacent to Sm's main executable (chrome.exe) and ALWAYS launch Sm via that (you can alternatively create a Windows shortcut with the same cmdline args) ; be mindful: "portable" apps are NOT meant to be associated with other protocols/files/applications etc. ...

Apparently, pastebin moderation has approved nicolaasjan's yt-dlp log and yesterday's 403 error is now gone: ... Just something to keep in mind in the event of future pastebin uploads (i.e., they might not be immediately visible, for reasons only known to pastebin themselves ) ...

Thanks ; that one works ...

... But :

Yet another case of site admins arbitrarily blocking less than current User Agent Strings... Yet the site loads when a SSUAO is used to impersonate latest FxESR-140 on Win10x64: general.useragent.override.zdoom.org;Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Using an extension to impersonate latest Chrome DEV (v144) makes it open in Sm-126, too : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36 PS: Sm-126 by default reports itself as being Cr-132 ...

As told, you don't have to install node system-wide; of the linked zip archive, for yt-dlp purposes, you only need the standalone (portable) "node.exe" binary ... Even simpler, just place "node.exe" (67.8 MiB) next to your yt-dlp 64-bit binary and issue/configure --js-runtimes node; if you're overly concerned about "security", you can let yt-dlp launch NODE in JIT-less mode via --js-runtimes node --extractor-args "youtube-ejs:jitless=true" (provides better security at the cost of performance/speed) ; according to online testimonies, Node takes just 1-2s to solve YT's challenges, while QuickJS, depending on how powerful your machine is, may take from 8-15s (and this relic of mine (32-bit OS, 3GB RAM, Core2 Duo from late 2007), can take anything from 15-30s, depending on how busy the machine is when qjs.exe starts ) ... I keep an eye on two things : 1. This; QuickJS-ng may, in due course, end up with "rope strings", too, so its speed (when used with yt-dlp) may become on par with upstream QuickJS 2. That; the astring library is an external dependency of the yt-dlp-ejs JS component which, together with a suitable JS runtime, performs the task of solving YT's JS challenges; hopefully, this PR will be accepted and merged into the astring repo and a future yt-dlp-ejs version will pick that updated version up, making the use of QuickJS-ng with yt-dlp equally "practical" ... Reference: here ...

Not my fault, really, but here you go: https://board.eclipse.cx/viewtopic.php?p=7539#p7539 https://board.eclipse.cx/viewtopic.php?p=7542#p7542 https://board.eclipse.cx/viewtopic.php?p=7593#p7593 There was this r3dfox bug and the author (thought he) found the solution in one of LibreWolf's special "policies", but while he was "there", he decided to also implement several other LW policies/settings into r3dfox; this is implied in the bolded wording of every new "LW-ified" r3dfox release, e.g. 128.14.1esr: Testimonies of breakage can be found in the linked Eclipse Forum thread and in the GH issue tracker (recent open/closed issues), e.g. https://github.com/Eclipse-Community/r3dfox/issues?q= is%3Aissue state%3Aopen sort%3Aupdated-desc https://github.com/Eclipse-Community/r3dfox/issues?q=is%3Aissue state%3Aclosed sort%3Aupdated-desc What made me furious the most was this ; but, as I wrote already, I'm only speaking for myself here; it may well be that the majority of the r3dfox users are still very happy to have got new releases with the latest security patches, courtesy of Mozilla .. As you often write, "moving on" ...

... Eclipse Board is now back in business (technically, it never went off-line) ... .. But I'd be very wary of ; both have been LibreWolf-ified ; I'd make a profile back-up prior to updating, in case one decides to revert to the previous ESRs (128.12.0rc2 and 140.2.0, respectively); just sayin' , not suggesting people shouldn't update...

Well, since your custom path to the QuickJS binary doesn't contain any whitespace, I feel no quotation marks of any type are needed after all ; personally, I'd only use "..." in the value part of the --js-runtimes flag, something like: --js-runtimes quickjs:"H:\path to\qjs-windows-x86_64.exe" For the sake of even more simplicity, I'd a) rename the QuickJS binary to just "qjs.exe" b) place it adjacent to "yt-dlp-win7-x64.exe" (which could also be renamed to just "yt-dlp.exe"); then, one would simply need issue --js-runtimes quickjs in the cmdline (or set an equivalent permanent setting inside yt-dlp's config file); more in https://github.com/yt-dlp/yt-dlp/issues/15012 https://github.com/yt-dlp/yt-dlp/wiki/EJS The use of QuickJS-ng is strongly discouraged, because they haven't yet implemented this ; since you're on Win7 SP1 64-bit, for even quicker n/sig deciphering you may want to switch to this NodeJS fork: https://github.com/vladimir-andreevich/node.js-windows-7/blob/main/v20/node-v20.19.2-win-x64.zip (node isn't enabled by default in yt-dlp, you need to issue --js-runtimes node (or use a custom path to the binary, if you must)) PS: It appears https://www.youtube.com/watch?v=Kzb6Vih7wrU is geo-fenced here ...

... And un-archived now : https://github.com/Eclipse-Community/r3dfox

The redfox-old GitHub repo was (also) archived today, but this was probably to be expected; no clue as to why its successor suffered the same fate today ... As for the Eclipse Board , they mention "Temporary maintenance" (stress on "temporary" is mine ) ... That ; and those "proposals" did materialise into a Librewolf-ification of r3dfox that many, myself included, never asked for ... As @Jody Thornton put it, ... and I'll add Vista SP2 to the OS mix above ; yes, close to "stock" Firefox but with the ability to launch on older WinOSes! This is what most site admins expect, this is what most extension authors expect and target... I was never part of the "extreme web privacy" crowd to demand a change of route towards Librewolf (or similar forks); I understand a small portion of the LW code was needed to address a specific r3dfox technical issue, but that is different to incorporating large chunks of LW code "while we're at it" ... As if it wasn't enough to deal with Mozilla "breaking" things (and locking down the browser) with each major version update, an "average" r3dfox user has to deal with "r3dfox-specific" changes, too (ones that not always meet with said user's "approval") ... And my own words on DRM/EME: I found r3dfox maintainer's "obsession" about DRM simply "blown out of proportion"; he goes to extreme lengths to disable EME at buildtime, but the browser itself provides an easy way to disable EME at runtime, if one objects to it for whatever ideological reason... Let's face it; with Google practically owning the Web, they have leveraged the use of their own CDM (Widevine) in most media services, even the most obscure, but still free, ones... Yes, I totally understand the argument about "black-boxed code" etc., but DRM has become a necessary evil in the web era of 2025 and beyond... A lot of focus has been put on the VMP (Verified Media Path) requirement associated with the majority of the prominent/commercial DRM'ed Video+Audio services (e.g. Netflix, Disney+, Paramount+, Spotify, Tidal, Apple Music, etc.) as a reason NOT to implement DRM on r3dfox (because VMP entails a very large sum of money, paid to Google, for certifying the browser for VMP purposes), but what about the rest of the lesser known services that don't impose VMP with DRM? Jody's example of https://www.cp24.com/now/ is such a case, there are many others... The whole thing kind of reminds me, in some twisted way, of Moonchild and his own browser, Pale Moon, where he vehemently refused to implement DRM of any kind; but while Basilisk was still his, he allowed the DRM functionality inherited from his FxESR-52 forkpoint to stay enabled; that is, until the point he could no longer shoehorn-in upstream (Mozilla) DRM patches and, one day, DRM in Basilisk was declared such a big Evil that had to be completely excised! (NB: Latest Widevine CDM (a .dll) needs Win8+ to properly function; on Vista/Win7, some wrapper DLLs (e.g. borrowed from the Supermium project ) are actually needed to make it work there (and only on non-VMP services)). I believe so; he probably had a "hissy fit" and decided to "now I'll show you all", or I could be totally wrong and the GitHub repo archival was an inadvertent mishap ... ... You can count me as one (though I did not post in that thread...). Personally, I'll stick to older r3dfox-140.0.4; it will become my new "KafanMiniBrowser" for GitHub; I'm not that concerned about security patches, as long as GH works there (and it'll continue to work until 140esr becomes deprecated), I'll keep using it... In closing, I'm not being entitled or ungrateful towards the r3dfox author; huge thanks from my side for what he has offered to me over the last two years or so ...

I can confirm; it's a "less heavy" G-Search iteration, probably more gentle to older/under-resourced H/W ; below, a glimpse of what an Image Search looks like: Should you wish to revert to the "full-blown" G-Search implementation, targeting so called "recent" web engines, just use a SSUAO for Google: general.useragent.override.google.com;Mozilla/5.0 (Windows NT 10.0; rv:140.0) Gecko/20100101 Firefox/140.0 And then, above image search will turn into: