Leaderboard

Replaced the XP build in the previous link. Added zlib to support png. Added libxml2 as suggested by @VistaLover.

@nicolaasjan Thanks for testing. We will go with a somewhat fuller build and make sure things are functional. A new build will replace the old one shortly.

And whose fault is that? Certainly NOT @autodidact's ; many users here, especially the "XP-die-hards", complained of "inflated" FFmpeg binary sizes; that they ONLY wanted a binary capable of just remuxing downloaded formats (and only with the h264/aac codecs) from youtube.com; nothing more; IOW, a "bare-bones" FFmpeg compile... So, "they" got what "they" asked for (and no more shared builds, on top of that) ... I, of course, was against such a request, because I also use FFmpeg outside of a yt-dlp context; e.g., the latest XP binary can't even fetch MPEG-DASH streams on its own, because it has been compiled without an XML parser (libxml2)); since I'm on Vista SP2 x86, I stayed silent, as the "Vista builds" (many thanks for those shared binaries, too ) continue to fulfill most of my needs under Vista; no complaints here of any sort, @autodidact !

@autodidact I tested your XP version of FFmpeg, but it failed to convert flac to mp3 due to missing codec/library (for parsing cover art): ffmpeg -threads 2 -y -i "Klaus Schulze - Mellotrone.flac" -acodec libmp3lame -q:a 0 "Klaus Schulze - Mellotrone.mp3" ffmpeg version N-124841-gb355200263-WINXP Copyright (c) 2000-2026 the FFmpeg developers built with gcc 14.3.1 (GCC) 20250901 configuration: --arch=x86 --target-os=mingw32 --prefix=/cygdrive/c/cygwin64/mingw-w64/i686-w64-mingw32 --cross-prefix=/cygdrive/c/cygwin64/mingw-w64/bin/i686-w64-mingw32- --extra-cflags='-O2 -mthreads -march=pentium4' --pkg-config=pkg-config --pkg-config-flags=--static --enable-gpl --enable-gray --enable-version3 --disable-bcrypt --disable-debug --disable-doc --disable-w32threads --disable-autodetect --disable-avdevice --enable-libmp3lame --enable-libfdk-aac --extra-version=WINXP libavutil 60. 32.100 / 60. 32.100 libavcodec 62. 36.101 / 62. 36.101 libavformat 62. 19.101 / 62. 19.101 libavfilter 11. 17.100 / 11. 17.100 libswscale 9. 8.100 / 9. 8.100 libswresample 6. 4.100 / 6. 4.100 Input #0, flac, from 'Klaus Schulze - Mellotrone.flac': Metadata: ARTIST : Klaus Schulze ALBUM : Contemporary Works I - CD 9 - Klaus Schulze: Ballett 4 GENRE : Electronic DATE : 2000 TITLE : Mellotrone DISCID : 220FE003 track : 1 TOTALTRACKS : 3 TRACKTOTAL : 3 Duration: 00:13:53.19, start: 0.000000, bitrate: 819 kb/s Stream #0:0: Audio: flac, 44100 Hz, stereo, s16 Stream #0:1: Video: png, none, 600x600, 90k tbr, 90k tbn (attached pic) Metadata: comment : Cover (front) title : cover.png [vost#0:0 @ 0003d580] Automatic encoder selection failed Default encoder for format mp3 (codec png) is probably disabled. Please choose an encoder manually. [vost#0:0 @ 0003d580] Error selecting an encoder Error opening output file Klaus Schulze - Mellotrone.mp3. Error opening output files: Encoder not found

FFmpeg update. XP: static shared libfdk-aac VISTAx86: shared static libfdk-aac

Yes, I didn't really agree with that . If they want a smaller size, they could compress it with UPX. For now, I have reverted to the previous 'full' version.

What matters on MSFN is the duration of the root certificate that the website's certificate is linked to. Many sites supply their own certificates that are linked to a trusted authority. ISRG Root X2 is valid until september 2040. Root YE is valid until september 2032, and YE2 until september 2028.

Good question! All Chrome-based browsers use WINDOWS'S "cert store". But I also *never* "update" Windows. But I've also *never* encountered "expired" certificates. And I'm also "deadset against" any (including those found at MSFN) "certificate updaters" (cause more harm than good). So yeah, good question, it would seem that my usage (and it sounds like yours too) would &/or should bump into "expired" certs - but again, I never have. In the past, for me at least, that was because I *created my own* certificate for PROXOMITRON and the browser only relied on that certificate. But I dropped Proxomitron in favor of all userscripts and userstyles about a year and a half ago (too many Cloudflare issues that requires Proxomitron [Reborn] to be bypassed). My gut reaction answer was that maybe certs are good for too long into the future so I've never hit an expiration. But MSFN's cert shows only THREE MONTHS between release date and expiration date. This Win10 install is WAY older than that! With no Windows Updates allowed! But no cert error here at MSFN. Sorry, none of that is really an "answer", per se, but adds intrigue to your question. Hmm...

for border issue, it could be https://repo.palemoon.org/MoonchildProductions/UXP/issues/3088 others are security related patches and I can't find which cause the slowness.

@Dietmar Yeeeeeeeeeeeaaaaaaaaa I built from scratch a bootvid.dll driver (hardcoded version) for WinXP 64-bit that can display a BSOD on the screen if OS boot in UEFI mode It only needs to hardcode the current graphics card memory address and the native resolution of the monitor: I also built a version that automatically finds the address of the graphics card but cannot read the current resolution and uses hardcoded resolution and displays the BSOD only well in hardcoded resolution. On any other resolution BSOD it is corrupt: But of course possible compile bootvid.dll auto-scan memory addres and use hardcoded any custom resolution e.g. popular 1920x1080

There has been a new release (finally ) by its author, Bellard, of the quickjs JS runtime, necessary for de-scrambling YouTube's nsig challenges (present on most yt_player_clients, except for ANDR-V); the 32-bit binary can be found on: https://bellard.org/quickjs/binary_releases/quickjs-win-i686-2026-06-04.zip (64-bit binary: https://bellard.org/quickjs/binary_releases/quickjs-win-x86_64-2026-06-04.zip) quickjs is the only supported JS runtime on "legacy" WinOSes, like XP SP3/Vista SP2/Win7 SP1; I can't check on XP SP3 x86, but the new release does launch here (Vista SP2 x86): qjs -h => QuickJS version 2026-06-04 usage: qjs [options] [file [args]] -h --help list options -e --eval EXPR evaluate EXPR -i --interactive go to interactive mode -m --module load as ES6 module (default=autodetect) --script load as ES6 script (default=autodetect) --strict force strict mode -I --include file include an additional file --std make 'std' and 'os' available to the loaded script -T --trace trace memory allocation -d --dump dump the memory usage stats --memory-limit n limit the memory usage to 'n' bytes (SI suffixes allowed) --stack-size n limit the stack size to 'n' bytes (SI suffixes allowed) --no-unhandled-rejection ignore unhandled promise rejections -s strip all the debug info --strip-source strip the source code -q --quit just instantiate the interpreter and quit Additionally, the quickjs-ng fork has also seen a new release: https://github.com/quickjs-ng/quickjs/releases/tag/v0.15.1 https://github.com/quickjs-ng/quickjs/releases/download/v0.15.1/qjs-windows-x86.exe This runtime officially supports Win7 SP1 and later, but it can also work under Vista SP2 (but NOT on XP SP3): qjs -h => QuickJS-ng version 0.15.1 usage: qjs [options] [file [args]] -h --help list options -v --version print version string and then exit -e --eval EXPR evaluate EXPR -i --interactive go to interactive mode -C --script load as JS classic script (default=autodetect) -m --module load as ES module (default=autodetect) -I --include file include an additional file --std make 'std', 'os' and 'bjson' available to script -T --trace trace memory allocation -d --dump dump the memory usage stats -D --dump-flags flags for dumping debug data (see DUMP_* defines) -c --compile FILE compile the given JS file as a standalone executable -o --out FILE output file for standalone executables --exe select the executable to use as the base, defaults to the current one --memory-limit n limit the memory usage to 'n' Kbytes --stack-size n limit the stack size to 'n' Kbytes -q --quit just instantiate the interpreter and quit Both are fully supported by latest yt-dlp; performance-wise, they shouldn't differ much, if at all...