VistaLover

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