Who here has a Youtube-DL compile for WinXP?

[user57]

i looked at it in doxygen QueryWorkingSet and Ex are doing partly the same thing
they call up  NtQueryVirtualMemory

where then both access the either "MemoryWorkingSetList" or "MemoryWorkingSetListEx" as parameter
//
typedef enum _MEMORY_INFORMATION_CLASS
{
    MemoryBasicInformation,
    MemoryWorkingSetList,       // <-- this 
    MemorySectionName,
    MemoryBasicVlmInformation,
    MemoryWorkingSetExList  // <-- and this
} MEMORY_INFORMATION_CLASS;
 

however on msdn they might look different:
(QueryWorkingSet)
typedef struct _PSAPI_WORKING_SET_INFORMATION {
  ULONG_PTR               NumberOfEntries;
  PSAPI_WORKING_SET_BLOCK WorkingSetInfo[1];
} PSAPI_WORKING_SET_INFORMATION, *PPSAPI_WORKING_SET_INFORMATION;

(QueryWorkingSetEx)
typedef struct _PSAPI_WORKING_SET_EX_INFORMATION {
  PVOID                      VirtualAddress;
  PSAPI_WORKING_SET_EX_BLOCK VirtualAttributes;
} PSAPI_WORKING_SET_EX_INFORMATION, *PPSAPI_WORKING_SET_EX_INFORMATION;

the parameter sizes are the same, so a linking to that function works, just maybe not fully functional
that we should keep an eye on if it behave different

if they behave different you have have to write a code that redirects to QueryWorkingSetEx to -> NtQueryVirtualMemory with that MemoryWorkingSetExList
xp might got this function parameter

[nicolaasjan]

Here is another test version, using the PR fork with EJS support (also works on Vista).

Instead of Deno, Windows 7 (and Vista) users can install QuickJS.

[TSNH]

6 hours ago, nicolaasjan said:

Here is another test version, using the PR fork with EJS support (also works on Vista).

Just tested on Vista seems to work well

[EliraFriesnan]

4 hours ago, TSNH said:

Just tested on Vista seems to work well

Does it work with proxies?

[nicolaasjan]

Support for EJS is now implemented in yt-dlp master branch. 

https://github.com/nicolaasjan/yt-dlp/releases/tag/2025.11.01.082330

[TSNH]

15 hours ago, EliraFriesnan said:

Does it work with proxies?

Don't have a good proxy to test right now

It's just that the previous version for Vista posted in this thread stopped working with you tube at all a few days ago and this new one works again

[johk]

For the shake of test I tried the Windows 7 (32bits) binary posted with quickjs (thanks to the developer of this tiny engine) and I wonder how powerful computers do the people that develop things have?

Literally, it hangs a few times through the compute, even for a fraction of a second, while resolving the YouTube challenge :/

Multiply that 2 times, as I check the available formats, and then download the desired format, and the benefits of downloading+playing performance vs viewing on the page, starts to vanish.

It has been requiring more and more compute time through time but... wow

Or the whole process gets optimized or... YouTube is winning by far.

For those interested, I only have a Core 2 Duo. As most here, old hardware, yes.

EDIT: I wasn't initially able to make the latest published x64 version (2025.11.01.082330) work with quickjs (my fault by setting the path "--js-runtimes quickjs:'c:\balbla\'" instead "--js-runtimes quickjs:'c:\balbla\qjs.exe'" because I didn't want a PATH path either ;) ) and maybe it has a slightly better performance, but not much.

EDIT2: as a side note, I know that the performance drop is not by yt-dlp, nor this build, but the damn YouTube JS and the JS engine, but... just ranting. Edited November 4 by johk

[roytam1]

trying to use QuickJS-ng but yt-dlp-win7-x64 can't get it?

>H:\apps\yt-dlp --js-runtimes quickjs:'H:\apps\qjs-windows-x86_64.exe' -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" --no-check-certificate --cookies "H:\apps\yt-cookie.txt" --write-subs --sub-langs zh-Hant,zh https://www.youtube.com/watch?v=Kzb6Vih7wrU

[youtube] Extracting URL: https://www.youtube.com/watch?v=Kzb6Vih7wrU
[youtube] Kzb6Vih7wrU: Downloading webpage
WARNING: [youtube] No supported JavaScript runtime could be found. YouTube extraction without a JS runtime has been deprecated, and some formats may be missing. See  https://github.com/yt-dlp/yt-dlp/wiki/EJS  for details on installing one.
To silence this warning, you can use  --extractor-args "youtube:player_client=default"
[youtube] Kzb6Vih7wrU: Downloading android sdkless player API JSON
[youtube] Kzb6Vih7wrU: Downloading web safari player API JSON
WARNING: [youtube] Kzb6Vih7wrU: Some web_safari client https formats have been skipped as they are missing a url. YouTube is forcing SABR streaming for this client. See  https://github.com/yt-dlp/yt-dlp/issues/12482  for more details
[youtube] Kzb6Vih7wrU: Downloading m3u8 information
WARNING: [youtube] Kzb6Vih7wrU: Some web client https formats have been skipped as they are missing a url. YouTube is forcing SABR streaming for this client. See  https://github.com/yt-dlp/yt-dlp/issues/12482  for more details
[info] Kzb6Vih7wrU: Downloading 1 format(s): 137+140
[info] There are no subtitles for the requested languages

EDIT: alright, instead of "--js-runtimes quickjs:'H:\apps\qjs-windows-x86_64.exe'", I need to remove single quotation marks: "--js-runtimes quickjs:H:\apps\qjs-windows-x86_64.exe" and use upstream QuickJS binary release for faster solving speed instead of QuickJS-ng.

[youtube] Extracting URL: https://www.youtube.com/watch?v=Kzb6Vih7wrU
[youtube] Kzb6Vih7wrU: Downloading webpage
[youtube] Kzb6Vih7wrU: Downloading tv client config
[youtube] Kzb6Vih7wrU: Downloading player ef5f17ca-main
[youtube] Kzb6Vih7wrU: Downloading tv player API JSON
[youtube] Kzb6Vih7wrU: Downloading android sdkless player API JSON
[youtube] [jsc:quickjs] Solving JS challenges using quickjs
[info] Kzb6Vih7wrU: Downloading 1 format(s): 137+140
[info] There are no subtitles for the requested languages

and mweb:

[youtube] Extracting URL: https://www.youtube.com/watch?v=Kzb6Vih7wrU
[youtube] Kzb6Vih7wrU: Downloading webpage
[youtube] Kzb6Vih7wrU: Downloading tv client config
[youtube] Kzb6Vih7wrU: Downloading player ef5f17ca-main
[youtube] Kzb6Vih7wrU: Downloading tv player API JSON
[youtube] Kzb6Vih7wrU: Downloading android sdkless player API JSON
[youtube] Kzb6Vih7wrU: Downloading mweb client config
[youtube] Kzb6Vih7wrU: Downloading mweb player API JSON
[youtube] [jsc:quickjs] Solving JS challenges using quickjs
[youtube] [jsc:quickjs] Solving JS challenges using quickjs
[info] Kzb6Vih7wrU: Downloading 1 format(s): 137+140
[info] There are no subtitles for the requested languages

maybe I don't need using mweb now.

Edited 1 hour ago by roytam1

[user57]

On 11/4/2025 at 12:56 AM, johk said:

For the shake of test I tried the Windows 7 (32bits) binary posted with quickjs (thanks to the developer of this tiny engine) and I wonder how powerful computers do the people that develop things have?

Literally, it hangs a few times through the compute, even for a fraction of a second, while resolving the YouTube challenge :/

Multiply that 2 times, as I check the available formats, and then download the desired format, and the benefits of downloading+playing performance vs viewing on the page, starts to vanish.

It has been requiring more and more compute time through time but... wow

Or the whole process gets optimized or... YouTube is winning by far.

For those interested, I only have a Core 2 Duo. As most here, old hardware, yes.
 

for me chrome was a big problem because it tooks 2 weeks to compile up, this is bad when you want to write something or testing the code

then the next problem was that the vm snapshots (only a few) already took up the 2 TB limit. so work was limited for example i could not compile a extra debug version (the compiler optimization can make problems)

also when clicking around they are more time consuming if they take time because these sum up 

windows 10 also is not the fastest horse, it has a lot a background activity - also it force upgrades neither if you dont want them nor you know they dig into your computer 

 

in total these things then sum up all together - when you have limited time it gets a even bigger problem

to install some new VS2022 compiler and win11 would take to much up - while a better computer still just could "eat it up anyway"