Who here has a Youtube-DL compile for WinXP?

[gaouser]

On 3/27/2025 at 2:06 AM, user57 said:

this might be a good moment to mention the "engine problem" again

first the one-core-api is giving a nice support for some win6+ apis 

since we talk about phyton stopping the xp support we can point out the engine question again

a engine often use functions of a certain OS, is written for that certain OS 

elder programming languages useally never had a such point
neither if it was c, c++, assembly, basic, delphi

because that are a programming language ... that dont need a certain "windows, linux, mac" function

today that is changing 

the new c++ styles often get tranlated into a different code (which then use a OS function) -> and then you have it your nt 6+ is involved
a such example would be the c-runtime - even tho you written a normal c++ code the c++ code still now involves that c-runtime
and that c-runtime use nt 6+ functions

for c++ mutex would be a such example
https://en.cppreference.com/w/cpp/thread/mutex
however there is not only a nt 6+ interpration for this (aka srw locks)
you also could use a thread based atom style to solve this problem 
there are some more, keyed_events, mutex windows functions as as createmutexa, creatthread styles, or criticalsection styles

when i saw a new project i saw the following problem
it uses DX11 
it uses phyton 
it uses cmake 
it needs VS2019 (aka new c++ styles + the c-runtime)
the project itself already where written with windows 10 functions

often you dont have insight into the things these use (i often call them engines)
lets say phyton break - then you cant compile it up because phyton decided to longer like xp
if cmake use nt6 then you also cant compile up
if visual studio wants a newer version you cant compile up
if directx wants a newer version of directx you also cant compile up

that makes it a lot to go through before you even can do anything

the new trends doing exactly so even ffmpeg is going into that direction (for example ffmpegs
cuda engine)

in this discussion it seems to be bond to phyton 

a possible solution would be a code translation from phyton to c++ (normal styles ones)
a good thing with c is that you can always have a c interpration in comparison to a other language without having a hard time with a lot of math like in assembly

assembly for example can represent any language - its because all languages create a assembly code in the end 
c++ made a good compromise (but new c++ styles going into a direction to be something like a java script)

im trying to point out that all of these try not to be just a programming language, they going into a different direction to like a script and engines

so if phyton is not possible anymore, i would suggest a translation to c++

UCRT itself uses WinSocks while my code doesn't...