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 yesterday 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 12 hours ago 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  ) ...