All Activity

I just noticed that when I copy a link from Google search using Supermium, I actually get the target link. But if I copy with an old browser, such as New Moon, I get the redicted link managed by Google. Why is it that Supermium has access to the true obfuscated link?

Yes, those are XP compatible. There are also binaries here, but they are Vista+.

... You'd also need to use "special" actions to: 1) explicitly request and setup adang1345's CPython mod (NT 6.0+ compatible); Microsoft's GitHub probably only knows of the official PSF versions (Win10+) 2) explicitly request and install a "special" version (fork) of PyInstaller to compile the yt-dlp "Win7" binaries (which are also compatible with Vista SP2). CPython versions, the PSF ones or even adang1345's, come with embedded OpenSSL binaries; IIUC, currently the swap of them with updated OpenSSL DLLs (e.g 3.6.1) is mainly a manual job; I can't imagine how this could be done in the context of a workflow, but what do I know? ... Many thanks, indeed ...

@roytam1, thank you for your work. The following websites are not displayed correctly in the browser: https://rutracker.org/ - site doesn't open at all. https://www.ozon.ru/ - the site doesn't open. This problem exists for older versions of Firefox. https://www.vseinstrumenti.ru/ - the site doesn't open. https://vkvideo.ru/ - a message appears when there is a memory read error. In my personal experience, the latest versions of the browser are slower, so I use version 2025.07.31.

I have no experience with Github workflow at all, but you can't set it up to utilize the latest Python and OpenSSL as well? I thought these are still WinXP compatible, are they not? Anyway... despite a small bump in the road I've compiled and uploaded OpenSSL 3.6.1.

Strictly a curiosity question. I'm not a gambler and I don't bet. But... Something has piqued my curiosity. This question pertains to "beating the spread" and just how that "works". A nearby NCAA basketball team has done "much better than average" this season, especially pre-conference play. So they keep landing in national news much more than often on account of that "success". But here is my "observation", they keep getting before-game "spreads" in DOUBLE DIGITS. But RARE are their double-digit WINS. Which leads to my curiousity... I can't help but be curious on how "betting" AGAINST them would have benefited anyone that may have bet them to LOSE. Because unless I'm mistaken, if the "spread" is DOUBLE DIGITS but they only win by SINGLE digits, then they technically LOST and betting for that LOSS is a *WIN*. So how much would a person have "won" if, purely as an example, say $100 was bet that they would NOT beat the spread in FIVE consecutive games and regardless of them WINNING those FIVE games, they DID NOT BEAT THE SPREAD, so they didn't "win" in that sense.

https://github.com/quickjs-ng/quickjs/pull/1324 has been merged into master: https://github.com/quickjs-ng/quickjs/commit/e85ae372edf32882c8b877cd770fe485f2b05147 Latest GHA workflow that has this implemented: https://github.com/quickjs-ng/quickjs/actions/runs/21545069744?pr=1324 win 32-bit binary (you only need the qjs-windows-x86.exe one): https://github.com/quickjs-ng/quickjs/actions/runs/21545069744/artifacts/5328824393 win 64-bit binary (you only need the qjs-windows-x86_64.exe one): https://github.com/quickjs-ng/quickjs/actions/runs/21545069744/artifacts/5328823672 Codewise, these artifacts correspond to a quickjs-ng-v0.11.0-77-git-20260131-g3213652 snapshot... Well, I never claimed any WinXP-compatibility myself ; the app authors officially support Win7+: https://quickjs-ng.github.io/quickjs/supported_platforms About the "InitOnceExecuteOnce" error thrown on WinXP: https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initonceexecuteonce So, I'm really "lucky" the app (even) runs on NT 6.0 (and "unofficial" Vista SP2 compatibility isn't a "given", as far as official support goes ) ...

I tried this on XP (renamed to qjs.exe), but when running `yt-dlp -v`, it throws this:

Yes, that one probably didn't include the modified `yt_dlp/update.py` file... The Windows 7 one from GitHub updates fine: yt-dlp -U Current version: nicolaasjan/yt-dlp@2026.01.29.071857 Latest version: nicolaasjan/yt-dlp@2026.01.30.064627 Current Build Hash: e13632c9721715691dbbc989030c42552301cd670c32f5388dfc39fe46aa1c15 Updating to nicolaasjan/yt-dlp@2026.01.30.064627 ... Updated yt-dlp to nicolaasjan/yt-dlp@2026.01.30.064627 No, I grabbed the two 32-bit dll's from an install of the updated OpenSSL from here. (the 64-bit ones from there are not usable, as I explained earlier in this thread) I have absolutely no idea how to compile that on Windows.

But to be clear; if you value the fact that your custom builds are compiled with the latest OpenSSL, then you shouldn't use `-U`, I guess? I mean... C:\>yt-dlp_nicolaasjan.exe -v [...] [debug] Python 3.14.2 (CPython AMD64 64bit) - Windows-11-10.0.26200-SP0 (OpenSSL 3.6.1 27 Jan 2026) C:\>yt-dlp_nicolaasjan.exe -U [...] Updated yt-dlp to stable@2026.01.29 from yt-dlp/yt-dlp C:\>yt-dlp_nicolaasjan.exe -v [...] [debug] Python 3.10.11 (CPython AMD64 64bit) - Windows-10-10.0.26200-SP0 (OpenSSL 1.1.1t 7 Feb 2023) The initial 'yt-dlp_nicolaasjan.exe' is from yt-dlp-test.zip. And btw, it updates from "yt-dlp/yt-dlp" instead of "nicolaasjan/yt-dlp". Or am I missing something? I thought you managed to compile it yourself...

Then it's easy to add my custom builds to it. They are different. And they can be updated with `yt-dlp -U`. PS, Do you plan to update your OpenSSL page?

Hello @space223 , can't say, there are no records of this codec with HDA2.DLL. Did you try already?

I know your custom (test-)builds in the past either had some extras or left out some specific upstream changes. Why then set up this Github workflow if there's no difference compared to upstream? I try to understand.

I let the GitHub workflow build releases (which should be identical to upstream) and when that's done, I manually add my (custom Python) compiled versions in the web interface. After that, I use a Python script to fetch all the files and generate the SHA-256 and SHA-512 checksum files locally. Then replace the ones GitHub created with these, in order to make the (custom) update function* of my versions work. (*after having synchronised my fork with upstream, I clone it locally and apply a diff to `./yt_dlp/update.py` and then use that source tree in my VM's to compile) While the workflow is still running, I grab the version number from it and use that to update it in my builds as well: Then locally e.g.: python devscripts/update-version.py -c "nicolaasjan/yt-dlp" -r "nicolaasjan/yt-dlp" "2026.01.30.064627" python devscripts/set-variant.py win7_exe python -m bundle.pyinstaller I admit it's a rather hacky procedure, but it works.

will this driver work for alc897?

Seems like the crash on Mypal68 is MSVC runtime related, on 2000 + BWC EK if installed using the default settings Mypal68 doesn't launch and crashes after loading CONCRT140 (similar to 9x on DW and FineSSE logs with -lf switch) but this can be fixed by either spoofing the app to XP or reinstalling the extended kernel with NT6 functions enabled. I guess FineSSE v32 might show something similar to that but I could be wrong, that clears out the reason why Mypal68 uses NT6+ functions. Update: I disabled Kexvista and ran Mypal68, looks like it crashes on MSVCP140 instead WATSON22.WLG

@nicolaasjan : Positive `quickjs-ng` developments : https://github.com/quickjs-ng/quickjs/issues/1002#issuecomment-3826547072

Only the official quickjs (32-bit) release natively supports Windows XP SP3 x86: https://bellard.org/quickjs/ https://bellard.org/quickjs/binary_releases/?C=M;O=D https://bellard.org/quickjs/binary_releases/quickjs-win-i686-2025-09-13.zip This fact has been stated earlier in this thread (but am lazy now to find the relevant post). ... And, if you're prepared to use "hacked-binaries" (binaries HexEdited to redirect XP-incompatible kernel functions to OCA/Wine/ReactOS DLLs, then there's this : (the "appeal" of NodeJS vs quickjs is that the former is many times quicker (pun intended) compared to the latter ...)

Alpha 016: Win ME / RM / DirectX 9c Success with MSI G41M4-F (7592) ICH7 HD AudioController ID VEN_8086&DEV_27D8 / Realtek ALC888S - line out (green also CS/RS/SS) So far no sound on Asus P5B (ADI1988A) and Asus P5KPL/1600 (VT1708B) Asus P5KPL/1600 black jack output has scratchy noise. All PCIE 1.0

As I'm out of touch as far as WinXP is concerned... do none of the supported JS runtimes work on WinXP? It's obvious you manually create the test-builds with the latest Python and OpenSSL versions, but what about the Github releases? What exactly are the differences between these and the official yt-dlp builds?

For anyone not up to speed; the reason why this is happening has been revealed by one of yt-dlp's major contributors: A lot has changed recently, so I've done some new testing. ios For me personally this player_client still works without a Javascript runtime and a 403 HTTP Error. Compared to me previous post `;formats=missing_pot` is needed though: FOR /F "delims=" %A IN (' yt-dlp.exe --extractor-args "youtube:player_client=ios;formats=missing_pot" -f "(bv[width<=1920]+ba)[protocol^=m3u8]" -O urls "https://www.youtube.com/watch?v=###########" ') DO @IF NOT DEFINED url[0] (SET url[0]=%A) ELSE (SET url[1]=%A) "C:\Program Files\MPC-HC\mpc-hc64.exe" "%url[0]%" /dub "%url[1]%" /close This oldschool method works fine, but as it requires two separate commands I always use my favorite command-line tool Xidel to create the following one-liner: FOR /F "delims=" %A IN ('yt-dlp.exe --extractor-args "youtube:player_client=ios;formats=missing_pot" -f "(bv[width<=1920]+ba)[protocol^=m3u8]" -O urls "https://www.youtube.com/watch?v=###########" ^| xidel -se "let $url:=x:lines($raw) return `\"C:\\Program Files\\MPC-HC\\mpc-hc64.exe\" \"{$url[1]}\" /dub \"{$url[2]}\" /close`"') DO @%A FOR /F "delims=" %A IN (' yt-dlp.exe --extractor-args "youtube:player_client=ios;formats=missing_pot" -f "(bv[width<=1920]+ba)[protocol^=m3u8]" -O urls "https://www.youtube.com/watch?v=###########" ^| xidel -se "let $url:=x:lines($raw) return `\"C:\\Program Files\\MPC-HC\\mpc-hc64.exe\" \"{$url[1]}\" /dub \"{$url[2]}\" /close`" ') DO @%A As an alternative to... -f "(bv[width<=1920]+ba)[protocol^=m3u8]" ...you could also use... -f "bv[width<=1920]+ba" -S "+proto" --format-sort-force web_safari This player_client does require a Javascript runtime (I'm using deno). It only provides the m3u8 protocol formats (audio and video combined), so no filtering is needed, which makes the one-liner very simple: FOR /F "delims=" %A IN (' yt-dlp.exe --extractor-args "youtube:player_client=web_safari" -f "[width<=1920]" -O urls "https://www.youtube.com/watch?v=###########" ') DO @"C:\Program Files\MPC-HC\mpc-hc64.exe" "%A" /close I'm not sure if this player_client provides anything larger than 1080p. If it doesn't, then `-f "[width<=1920]"` isn't needed. As mentioned earlier, most of the time I now use LibreWolf to watch ad-free Youtube videos. I do remember getting the "Sign in to confirm you’re not a bot." message after having watched a dozen Youtube videos through yt-dlp and MPC-HC. Maybe "--impersonate firefox" could prevent that from happening?

New build of post-deprecated Serpent/moebius for XP! * Notice: This repo will not be built on regular schedule, and changes are experimental as usual. ** Current moebius patch level should be on par with 52.9, but some security patches can not be applied/ported due to source milestone differences between versions. Test binary: Win32 https://o.rthost.win/basilisk/basilisk55-win32-git-20260131-ccd77452d-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk55-win64-git-20260131-ccd77452d-xpmod.7z repo: https://github.com/roytam1/basilisk55 Repo changes: - Revert "Issue #2895 - Replace XorShift128+ with Xoroshiro128++" (37c42449b) - Revert "Revert "Issue #2895 - Replace XorShift128+ with Xoroshiro128++"" (b2538bd2b) - js-random: reorder Xoroshiro128++ code flow to reduce intermediate registers (1bef7770a) - import from UXP: Issue #2914 - Explicitly allow mixed content websockets on localhost. (151ef218) (c6ea29e45) - import from UXP: Issue #2828 - Follow-up: Simplify rule node tracking and ensure rule walker state isn't reset for the first child processor (226a443c) (3ec860974) - import from UXP: Issue #2916 - Restore the ability to set a default log level when using MOZ_LOG (a8960dc4) (5bbaf8608) - import from UXP: - Issue #2889 - Follow-up: Update eventPtr/eventEndPtr for XML_ParseBuffer (4b983c32) - Issue #2889 - Follow-up: Add patch for XML_ParseBuffer. (e5497c84) (2928eda48) - import mergediff of "Issue #2895 - Implement 32-bit compatible Xoroshiro128++" (02a89e14e) - ported from UXP: Whitespace Compatibility for ICU 72+ (20525d23) (fbc076eed) - import from UXP: - MoonchildProductions/UXP#2351 - Fix webrtc video encoding on macos (3224ec7d) - MoonchildProductions/UXP#2351 - Fix webrtc for Windows and Linux based on MacOS fix (1d03a05e) (139d0772b) - import from UXP: Issue #2403 - Implement SubmitEvent functionality (#2919) (9b3d172a) (ccd77452d)

New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rthost.win/boc-uxp/mailnews.win32-20260131-40a79c75-uxp-6ee9e34e29-xpmod.7z BNavigator Win32 https://o.rthost.win/boc-uxp/bnavigator.win32-20260131-40a79c75-uxp-6ee9e34e29-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/boc-uxp/tree/custom * Notice: the profile prefix (i.e. parent folder names) are also changed since 2020-08-15 build, you may rename their names before using new binaries when updating from builds before 2020-08-15. -- New build of HBL-UXP for XP! Test binary: IceDove-UXP(mail) https://o.rthost.win/hbl-uxp/icedove.win32-20260131-id-656ea98-uxp-6ee9e34e29-xpmod.7z IceApe-UXP(suite) https://o.rthost.win/hbl-uxp/iceape.win32-20260131-id-656ea98-ia-c642e3c-uxp-6ee9e34e29-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/icedove-uxp/tree/winbuild https://github.com/roytam1/iceape-uxp/tree/winbuild

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260131-3219d2d-uxp-6ee9e34e29-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260131-3219d2d-uxp-6ee9e34e29-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260131-3219d2d-uxp-6ee9e34e29-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260131-d849524bd-uxp-6ee9e34e29-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260131-d849524bd-uxp-6ee9e34e29-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260131-d849524bd-uxp-6ee9e34e29-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260131-d849524bd-uxp-6ee9e34e29-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260131-d849524bd-uxp-6ee9e34e29-w7plus-avx2.7z Official UXP changes picked since my last build: - Issue #2914 - Explicitly allow mixed content websockets on localhost. (151ef21890) - Issue #2828 - Follow-up: Simplify rule node tracking and ensure rule walker state isn't reset for the first child processor (226a443c96) - Issue #2916 - Restore the ability to set a default log level when using MOZ_LOG (a8960dc462) - Issue #2889 - Follow-up: Update eventPtr/eventEndPtr for XML_ParseBuffer (4b983c32b0) - Issue #2889 - Follow-up: Add patch for XML_ParseBuffer. (e5497c8425) - Issue #2895 - Implement 32-bit compatible Xoroshiro128++ (0dbad452e6) - MoonchildProductions/UXP#2351 - Fix webrtc video encoding on macos (3224ec7ddd) - MoonchildProductions/UXP#2351 - Fix webrtc for Windows and Linux based on MacOS fix (1d03a05e54) - Whitespace Compatibility for ICU 72+ (20525d238b) - Issue #2403 - Implement SubmitEvent functionality (#2919) (9b3d172a95) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes picked since my last build: - import from mozilla: Bug 2010411 - CLDR 48 'h' hour format is possibly web incompatible (3b9a3ec8e0) - Revert "Issue #2895 - Replace XorShift128+ with Xoroshiro128++" (75ca0c37f8) - Revert "Revert "Issue #2895 - Replace XorShift128+ with Xoroshiro128++"" (952e3022b8) - js-random: reorder Xoroshiro128++ code flow to reduce intermediate registers (454565b2ac) Update Notice: - You may delete file named icudt*.dat and icu63.dll inside program folder when updating from old releases. * Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

Roy, Just wanted to let you know that today's 55 basilisk release fixes the issue of pages not updating.