Who here has a Youtube-DL compile for WinXP?

[nicolaasjan]

17 hours ago, VistaLover said:

@nicolaasjan : Positive `quickjs-ng` developments  : 

https://github.com/quickjs-ng/quickjs/issues/1002#issuecomment-3826547072

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

[VistaLover]

21 hours ago, VistaLover said:

Positive `quickjs-ng` developments

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

3 hours ago, nicolaasjan said:

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

Well, I never claimed any WinXP-compatibility myself ; the app authors officially support Win7+:

https://quickjs-ng.github.io/quickjs/supported_platforms

Quote

Windows    >= Windows 7*    |     VS >= 2022 and Clang are supported; requires <stdatomic.h>

*: Windows 7 is EOL and only supported in this project as long as it doesn't interfere with its progress.

About the "InitOnceExecuteOnce" error thrown on WinXP: 

https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initonceexecuteonce

Quote

Minimum supported client |  Windows Vista [desktop apps | UWP apps]

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

Edited Saturday at 10:28 PM by VistaLover

[Reino]

8 hours ago, nicolaasjan said:

The Windows 7 one from GitHub updates fine:

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?

8 hours ago, nicolaasjan said:

No, I grabbed the two 32-bit dll's from an install of the updated OpenSSL from here. 

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.

[VistaLover]

1 hour ago, Reino said:

... but you can't set it up to utilize the latest Python and OpenSSL as well?

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

1 hour ago, Reino said:

I've compiled and uploaded OpenSSL 3.6.1

Many thanks, indeed  ...

[nicolaasjan]

5 hours ago, Reino said:

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.

Yes, those are XP compatible.

There are also binaries here, but they are Vista+.

[Reino]

4 hours ago, nicolaasjan said:

Yes, those are XP compatible.

Then why do you need mine? 

16 hours ago, nicolaasjan said:

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

While I was at it (compiling OpenSSL) I've had a look at this, but I couldn't compile quickjs. The culprit is undoubtedly "Add cross-platform Atomics support". I think it will be extremely difficult to restore WinXP compatibility. Attempting this at all, I think a patch similar to how I (with the help of Gianluigi "sherpya" Tiesi) restored WinXP compatibility to libaom back in the day is needed. We could ask him to have a look?

Edited yesterday at 10:53 AM by Reino

[user57]

thats a simple function kernel extenders have it already somewhere

however it would be better to use dependency walker to see if there are more 

[nicolaasjan]

Quote

Then why do you need mine? 

I don't need them now, but others might prefer them.

What I'm wondering is, why are your dll's larger in file size than the ones from here? 

• libcrypto-3.dll: 5.19MB vs 4.38MB
• libssl-3.dll: 1.21MB vs 1.01MB

More features?

[nicolaasjan]

4 hours ago, Reino said:

Then why do you need mine? 

I don't need them now, but others might prefer them.

What I'm wondering is, why are your dll's larger in file size than the ones from here? 

• libcrypto-3.dll: 5.19MB vs 4.38MB
• libssl-3.dll: 1.21MB vs 1.01MB

More features?

 

[VistaLover]

5 hours ago, nicolaasjan said:

What I'm wondering is, why are your dll's larger in file size than the ones from here? 

• libcrypto-3.dll: 5.19MB vs 4.38MB
• libssl-3.dll: 1.21MB vs 1.01MB

I investigated this myself and the reason appears to be that @Reino's DLLs haven't been "stripped" post successful compilation  : 

https://en.wikipedia.org/wiki/Strip_(Unix)

Quote

strip is a shell command for removing information from binary executable programs and object files that is not required for execution – typically including debugging data, symbol tables, relocation information, and other metadata. The resulting file will have a smaller size, this is also known as a stripped binary.[1]

In an MSYS2 environment, 

$ strip libssl-3.dll

will reduce the filesize from 1.22 MiB to just 890 KiB, while 

$ strip libcrypto-3.dll

will reduce the filesize from 5.20 MiB to just 3.88 MiB

Finally, as a general observation, different compilers will produce binaries with different filesizes, even when the source code is always the same; and, of course, using different compilation flags between two different compiler invocations will also produce binaries with (slightly?) different filesizes, even when the compiler and source remain unchanged...

The DLLs obtained from slproweb were compiled using a "CL" compiler (MSVC C/C++), as you can see by running: 

openssl version -a =>

OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 27 Jan 2026)
built on: Wed Jan 28 15:01:03 2026 UTC

platform: VC-WIN32
options:  bn(64,32)
compiler: cl  /Z7 /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG" -D_USE_32BIT_TIME_T -D_WINSOCK_DEPRECATED_NO_WARNINGS -D_WIN32_WINNT=0x0501

OPENSSLDIR: "C:\Program Files (x86)\Common Files\SSL"
ENGINESDIR: "C:\Program Files (x86)\OpenSSL\lib\engines-3"
MODULESDIR: "C:\Program Files (x86)\OpenSSL\lib\ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0x0000e39defebffff:0x0000000000000000:0x0000000000000000:0x0000000000000000:0x0000000000000000

These two are also linked to vcruntime140.dll (external MSVC dependency, thus this further reduces the DLLs's filesize).

My educated guess is that Reino's DLLs were compiled with some flavour of MinGW/MSYS2 (as can be deduced from the linked GH issue ), and that compiler is known to produce larger binaries than MS's Visual Studio (but I could be wrong somewhere, without knowing all the finer details  ) ...

[Reino]

2 hours ago, VistaLover said:

I investigated this myself and the reason appears to be that @Reino's DLLs haven't been "stripped" post successful compilation  :

They are actually and always have been.
I don't update the upstream script anymore, but all that I locally changed was "openssl-3.3.1" to "openssl-3.6.1".

2 hours ago, VistaLover said:

My educated guess is that Reino's DLLs were compiled with some flavour of MinGW/MSYS2 (as can be deduced from the linked GH issue ), and that compiler is known to produce larger binaries than MS's Visual Studio (but I could be wrong somewhere, without knowing all the finer details  ) ...

https://github.com/Reino17/ffmpeg-windows-build-helpers/blob/master/ffmpeg_local_builds/cross_compile_ffmpeg.sh#L78-L104

C:\>openssl.exe version -a
OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 27 Jan 2026)
built on: Sat Jan 31 22:56:33 2026 UTC
platform: mingw
options:  bn(64,32)
compiler: /cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc -m32 -O2 -march=pentium3 -mtune=athlon-xp -mfpmath=sse -msse -DL_ENDIAN -DOPENSSL_PIC -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -D_WIN32_WINNT=0x501
OPENSSLDIR: "/cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/ssl"
ENGINESDIR: "/cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/lib/engines-3"
MODULESDIR: "/cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/lib/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0xfed8320b078bffff:0x00405fc6f1bf97a9:0x0000003000000110:0x0000000000000000:0x0000000000000000

The last time I've updated the "MingGW-w64 Build Script" was 18 Sep 2022.

[nicolaasjan]

I would like to know how to compile this on Windows 10 with MinGW/MSYS2. 

Edited 8 hours ago by nicolaasjan

[VistaLover]

16 hours ago, Reino said:

They are actually and always have been

Respectfully, this doesn't add up at all with my findings, which should be possible to reproduce by others (and why would I publicly post untruths in the first place? ) ...

I'm always talking about the 3.6.1 (32-bit) DLLs contained in the following archive: 

https://rwijnsma.home.xs4all.nl/files/openssl/openssl-3.6.1-win32-shared-dev-xpmod-sse.7z

As I've posted previously in this thread, I keep a 2017-era copy of MABS (media-autobuild-suite) and if the DLLs had indeed been stripped, then submitting them to a "second" strip-treatment wouldn't result in filesize reduction; however, as I've posted already, I noticed that: 

19 hours ago, VistaLover said:

In an MSYS2 environment, 

$ strip libssl-3.dll

will reduce the filesize from 1.22 MiB to just 890 KiB, while 

$ strip libcrypto-3.dll

will reduce the filesize from 5.20 MiB to just 3.88 MiB

Proof from an actual mintty window: 

OTOH, your static openssl.exe (32-bit) binary contained inside archive

https://rwijnsma.home.xs4all.nl/files/openssl/openssl-3.6.1-win32-static-dev-xpmod-sse.7z

is indeed a "stripped" binary, because: 

Regards.

Edited 1 hour ago by VistaLover

[VistaLover]

On 2/1/2026 at 5:28 PM, nicolaasjan said:

I don't need them now, but others might prefer them.

FWIW, I don't believe that the slproweb distributed binaries have been optimised to load on SSE-only CPUs (I don't have the ability to test this hypothesis, though  ), which is the case with Reino's DLLs. Personally, I prefer his for TLS-fingerprinting reasons...

During recent months, many popular web services have been put behind aggressive anti-bot/anti-AI filters run by Cloudflare  ; these filters treat web requests by yt-dlp as originating from a non-browser client (this is true, of course ) and block them "with prejudice"   . 

On supported platforms (Windows 64-bit >= Win7), these blocks can be mitigated (not always successfully) by using the optional curl_cffi yt-dlp dependency and the associated "--impersonate" cmdline flag; but on 32-bit, especially when < Win7, this method can't be used  ...

One has to try other means of modifying yt-dlp's web requests, so as for them to have TLS fingerprints slightly different from the values inside CF's blocklists; in some cases, the use of the "--legacy-server-connect" flag might be enough, but usually it's not... Another method is to load the web service in a sanctioned browser, then extract session cookies and pass them to yt-dlp, along with the exact --user-agent the cookies came from; doesn't always work.

If you are in a position to update the OpenSSL version bundled with the CPython installation used to launch yt-dlp with, then you have best hopes of beating CF's block (because their blocklists contain values generated from "stock" CPython versions, containing whatever "default" OpenSSL version assigned by PSF; usually one of the 3.0.x LTS branch). 

It's under the above scenario that Reino's DLLs can prove most helpful, because a) with their "special" configuration, they generate TLS-fingerprints deviating (in a good way) from a standard/mainline OpenSSL binary (like the ones from slproweb/overbyte) b) the link to them is less "prominent" in the web, so less prone to be found by CF personnel/bots  and their TLS-fingerprints added inside an anti-bot filter; I have found these DLLs to be quite successful in "tough" cases, like the "dailymotion.com" one; so, many thanks Reino for those  ...

Best regards.

Edited 1 hour ago by VistaLover

[nicolaasjan]

Ah, I see.

Then I'm good to go on my main system with my own self-compiled OpenSSL libraries used by Python.

These are nowhere to be found on the web.