Windows XP compatible non-SSE2 FFmpeg binaries

[Reino]

On Zeranoe (https://forum.doom9.org/member.php?u=200225)'s forum I had a topic where once every 4 months I would post new FFmpeg binaries that are Windows XP compatible and will work on old CPUs without SSE2 instruction sets (like my own AMD Athlon XP 3200+).
Because Zeranoe took down his forum not so long ago I thought I'd create a topic here on Doom9 in the hope some of you might still find these binaries useful.

This all began end 2016 when (as far as I could tell) no one was willing to create WinXP- and old-CPU compatible FFmpeg binaries anymore.
Windows XP doesn't support TLS 1.2 and the latest compatible FFmpeg binary back then couldn't open TLS 1.2 encrypted https-urls either, which a lot of websites started using. This was the main reason I wanted to see if I could compile my own FFmpeg binaries. With the help of a third-party cryptography-library (OpenSSL, GnuTLS, or MbedTLS) I could solve that issue.
I had never compiled software before. In fact, it was literally my first encounter with Linux (Cygwin) Bash! But after my first attempts (https://github.com/rdp/ffmpeg-windows-build-helpers/issues/219) I forked Roger Pack's cross-compilation-script (https://github.com/rdp/ffmpeg-windows-build-helpers) and the rest is history.

Binaries: https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D (https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D)
Github: https://github.com/Reino17/ffmpeg-windows-build-helpers (https://github.com/Reino17/ffmpeg-windows-build-helpers)

My FFmpeg binaries are compiled with --enable-libfdk-aac, but they don't contain the actual code because of an incompatible license. You can download libfdk-aac separately here (https://rwijnsma.home.xs4all.nl/files/ffmpeg/libfdk-aac/?C=M;O=D) and put the dll-file in the same folder as 'ffmpeg.exe', or in any folder listed in the %PATH%-variable.
This was made possible with the help of a patch created by Gianluigi (https://oss.netfarm.it/mplayer/) Tiesi (https://github.com/sherpya/mplayer-be).

My FFmpeg binaries are also compiled with --enable-frei0r. You can download frei0r video filtering plugins separately here (https://rwijnsma.home.xs4all.nl/files/ffmpeg/frei0r/?C=M;O=D) and put the 'frei0r-1' folder in the same folder as 'ffmpeg.exe'.
This was also made possible with the help of a patch created by Gianluigi Tiesi.

Build-configuration:

--arch=x86
--target-os=mingw32
--prefix=/cygdrive/[...]/cross_compilers/mingw-w64-i686/i686-w64-mingw32
--cross-prefix=/cygdrive/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-
--extra-cflags='-O2 -march=pentium3 -mtune=athlon-xp -mfpmath=sse -msse'
--pkg-config=pkg-config --pkg-config-flags=--static
--extra-version=Reino
--enable-gpl
--enable-gray
--enable-version3
--disable-bcrypt
--disable-debug
--disable-doc
--disable-htmlpages
--disable-manpages
--disable-mediafoundation
--disable-podpages
--disable-txtpages
--disable-w32threads
--enable-avisynth
--enable-frei0r
--enable-filter=frei0r
--enable-gmp
--enable-libaom
--enable-libass
--enable-libfdk-aac
--enable-libflite
--enable-libfontconfig
--enable-libfreetype
--enable-libfribidi
--enable-libgme
--enable-libjxl
--enable-libmp3lame
--enable-libopenmpt
--enable-libopus
--enable-librubberband
--enable-libsoxr
--enable-libtwolame
--enable-libvidstab
--enable-libvorbis
--enable-libvpx
--enable-libwebp
--enable-libx264
--enable-libx265
--enable-libxml2
--enable-libxvid
--enable-libzimg
--enable-mbedtls

Changelog 01-09-2024:
FFmpeg buildscript:
xz 5.4.6 --> 5.6.2
SDL2 2.30.3 --> 2.30.6
freetype 2.13.2 --> 2.13.3
mbedtls 2.28.8 --> 2.28.9
mpg123 1.32.6 --> 1.32.7
libopenmpt 0.7.6 --> 0.7.9
harfbuzz 8.4.0 --> 9.0.0
*git --> latest commit

ffmpeg 7.1-596-5bc3b7f (N-115062) --> 7.1-2362-6aafe61 (N-116828)

Optional external libraries for use with FFmpeg:
frei0r-plugins 2.3.2-16-fdc9f32 --> 2.3.3-3-cbb507d

[manolito]

Many thanks... :D

I already downloaded the new builds, also the new ffms2 C-plugin. Will start testing right away. And it is good to see you supporting your builds here at Doom9, should give you more visibility compared to the deceased Zeranoe forum.

Cheers
manolito

[manolito]

Sorry, no joy this time with both ffmpeg builds (static and shared)... :confused:

The new ffms2 build seems to work fine so far (only made two test encodes). But both ffmpeg builds crash immediately after calling them. I get the old error popup which is very familiar. No idea if it is WinXP, or if the missing SSE2 capability causes it.

https://i.postimg.cc/pLPyRFnp/ffmpeg-error.png (https://postimages.org/)

Cheers
manolito

[FranceBB]

Sweet. I still gotta test the new builds, but just like I said on MSFN last year: Doom9 is the international encoding forum and pretty much everyone is here, so you're definitely gonna have more visibility than on the zeranoe's forum.
Anyway, thank you for the builds, I'll try them as soon as I get back home! :)

[lvqcl]

The error text in english is probably this:
"The NtCreateFile API failed. This error should never be returned to an application, it is a place holder for the Windows Lan Manager Redirector to use in its internal error mapping routines"

Also, found this: https://github.com/msys2/MINGW-packages/issues/5139#issuecomment-479645419

[Reino]

I get the old error popup which is very familiar.Hmm, this is very strange, because here on WinXP Pro SP3 my binaries run just fine.
Doing a search for "NtCreateFile" returns:
[...]\i686-w64-mingw32\include\ddk\ntifs.h
[...]\i686-w64-mingw32\include\winternl.h
[...]\i686-w64-mingw32\lib\libntdll.a
[...]\i686-w64-mingw32\lib\libntoskrnl.a
These are all MinGW-w64 7.0.0 files. My binaries from 4 months ago were also already compiled with MinGW-w64 7.0.0 and if I remember correctly you didn't have any problems with these binaries. At the moment I don't know what to make of this.

Also, found this: https://github.com/msys2/MINGW-packages/issues/5139#issuecomment-479645419I'm using Cygwin 2.874, the latest WinXP compatible version. And I'm not using winpthreads, but pthreads-w32.
It could be that something else in the MinGW-w64 buildscript is causing this though.

[manolito]

My binaries from 4 months ago were also already compiled with MinGW-w64 7.0.0 and if I remember correctly you didn't have any problems with these binaries.

Correct, your binaries from 4 months ago do run just fine on my old computer... :confused:

My system is absolutely standard, the CPU is an Intel Celeron Coppermine 1.1 GHz.

https://i.postimg.cc/Kz69tjcX/system.png (https://postimages.org/)

If you need any more information, just let me know. For now I am back to the older version...
BTW the new libfdk DLL works just fine with the older ffmpeg binary. Is it safe to use it, or are there any catches?

[Reino]

Maybe you could run the binary through Dependency Walker (https://www.dependencywalker.com/) and see what it has to say.

I also came across "Bugs in NTDLL.dll of non-english editions of Windows® XP" (https://skanthak.homepage.t-online.de/fubar.html). This website claims - if I understand correctly - the issue you're experiencing could be a bug in 'NTDLL.dll' of your German Windows XP because of a specific security update.

[manolito]

Did some more troubleshooting, this is what I found:

First of all FFMpeg, FFPlay and FFProbe all behave identical, they all display the same error message.

My ancient desktop machine has been updated with the PosReady updates as long as they worked, no other software has problems with it. I have two other XP laptops which were not updated with the PosReady updates, and I tried to replace NTDLL.dll on my desktop with older versions of this file from the laptops. No luck, these older versions prevented the desktop computer from booting altogether with a WinLogon error.

Then I used DependencyWalker on the desktop testing both the 4 months old build plus the new build. The results are here:
https://www.sendspace.com/file/6cnfxq

The old build also shows a couple of missing dependencies, but it does work.


I then retrieved the other two XP laptops from the vault and tested the new FFmpeg build there. Both laptops were updated up to the last official XP updates, but no PosReady updates.

The first laptop was an old Medion Netbook Akoya E1210 (made by MSI) with an Intel Atom CPU. SSE2 capable. This time FFmpeg also crashed, but the error message was different. This time it said that the application could not start because of a missing MFPlat.dll file.

The other XP laptop was a Medion Akoya 96360 with an AMD Turion64 X2 CPU, also SSE2 capable. Same error as above.


So these crashes have nothing to do with the SSE2 capability of the CPU, it is solely WinXP related. And I really wonder why these new binaries work on your AMD Athlon CPU...


//EDIT//
Could it be that your latest builds rely on some Windows Media Foundation functions which are not available under WinXP? Is it possible to remove the Media Foundation requirements from the build script?

[StainlessS]

No idea if anybody can make any sense out of below,
is KDiff of both results from dependency walker posted by Mani,
Left is from older one "ffmpeg-4.3-3133-1128aa8-win32-static-xpmod-sse.dwi", right from newer "ffmpeg-4.4-853-276d86a-win32-static-xpmod-sse.dwi".
At the end, older working one is cut off after new one exits with error.

As Png files [for those that dont have kdiff or other installed]

1) https://i.postimg.cc/F1vRdG4d/1.png (https://postimg.cc/F1vRdG4d)

2) https://i.postimg.cc/YjxS1grX/2.png (https://postimg.cc/YjxS1grX)

3) https://i.postimg.cc/HVsk3xjT/3.png (https://postimg.cc/HVsk3xjT)

4) https://i.postimg.cc/nCRcWJQB/4.png (https://postimg.cc/nCRcWJQB)

5) https://i.postimg.cc/3kkJ5cg6/5.png (https://postimg.cc/3kkJ5cg6)

EDIT: I missed out less interesting/matching sections.
EDIT: Old one fails to find module QUSEREX.dll, new fails to find MFPLAT.dll.

Could it be that your latest builds rely on some Windows Media Foundation functions which are not available under WinXP? Is it possible to remove the Media Foundation requirements from the build script?
MFPLAT.dll. might be media foundation.
uses these from MFPLAT.dll

MFCreateAlignedMemoryBuffer
MFCreateMediaType
MFCreateSample
MFShutdown
MFStartup

[lvqcl]

From ffmpeg Changelog:
version 4.3:
...
- MediaFoundation encoder wrapper

from configure:
--enable-mediafoundation enable encoding via MediaFoundation [auto]

I suppose that the latest binaries were built on a modern computer and MediaFoundation encoder was auto-enabled.
Then the obvious solution is to recompile it with --disable-mediafoundation option.

[FranceBB]

Actually, I haven't experienced the same problems you guys are facing.
It might be because of several reasons, but on my computer it works like a charm: Screenshot (https://i.imgur.com/cZW6agd.png)
https://i.imgur.com/RfiVE24.png
Windows XP x86 all updates + POSReady Updates 'till June 2019 + custom kernel with PAE Enabled.
My Intel Xeon CPU supports SSE, SSE2, SSSE3, SSE4.1, SSE4.2, though.
I'm not sure whether the issues you guys are facing are related to your CPU instructions set or if it's due to the fact that I'm using One Core API (custom kernel with backported functions).
Anyway, it works over here. Same goes for ffms2 C plugin which works like a charm.

[Reino]

Hmm, this is getting weirder and weirder.
And I really wonder why these new binaries work on your AMD Athlon CPU...Maybe the fact that I'm using a highly optimized WinXP iso has something to do with it. I don't know.
https://thumbs2.imgbox.com/4c/bf/krLMx7lP_t.png (https://images2.imgbox.com/4c/bf/krLMx7lP_o.png)

As far as the "The NtCreateFile API failed"-error is concerned, it's really strange that only your German localized WinXP suffers from this. FranceBB, your WinXP is English (International)?
I can't imagine any of the changes in 'cross_compile_ffmpeg.sh' are the cause of this, so this night I'll put my pc to work and revert gcc to 9.3.0 and maybe revert binutils and the others too.


Old one fails to find module QUSEREX.dllHere too:
LoadLibraryA("C:\WINDOWS\system32\QUSEREX.DLL") called from "FFMPEG-4.4-853-276D86A-WIN32-STATIC-XPMOD-SSE.EXE" at address 0x01AEBA86.
LoadLibraryA("C:\WINDOWS\system32\QUSEREX.DLL") returned NULL. Error: The specified module could not be found (126).
GetProcAddress(0x00000000, "QueueUserAPCEx_Init") called from "FFMPEG-4.4-853-276D86A-WIN32-STATIC-XPMOD-SSE.EXE" at address 0x01AEB915 and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x77C10000 [MSVCRT.DLL], "___lc_codepage_func") called from "FFMPEG-4.4-853-276D86A-WIN32-STATIC-XPMOD-SSE.EXE" at address 0x0270D40E and returned 0x77C330F4.
I have no idea what it is, but at least it doesn't crash the binary. Loading Gianluigi (Sherpya) his binary in Dependency Walker I don't get this log message.

I suppose that the latest binaries were built on a modern computer and MediaFoundation encoder was auto-enabled.
Then the obvious solution is to recompile it with --disable-mediafoundation option.No, I also compile on my AMD Athlon XP pc.
In 'ffbuild/config.log' I can indeed see mediafoundation=yes. Even though there's no reason not to autodetect MediaFoundation, because FFmpeg doesn't support WinXP anymore after all, it's really strange it is detected in my case. I guess I'll have to add --disable-mediafoundation.

[manolito]

Problem solved...

Reino just sent me a test build compiled with "--disable-mediafoundation", and this build works without any problems. :D

Thanks so much to Reino,

Cheers
manolito

[FranceBB]

FranceBB, your WinXP is English (International)?

Yep. EN US (International).
I changed it in 2013 as I didn't like the localized one I had from 2001 to 2013 anymore and I wanted everything to be in English. (There's probably a post on MSFN buried somewhere in the XP section)

Problem solved...

Reino just sent me a test build compiled with "--disable-mediafoundation", and this build works without any problems. :D

I'm glad that it's working fine on your end as well now. :)
Anyway, thank you Reino and long live to XP.

[Reino]

I guess it was --disable-mediafoundation after all. So no need to revert anything in the MinGW-w64 buildscript.
I've recompiled and replaced all 3 FFmpeg archives, as well as FFMS2, just to be sure.

[manolito]

Beautiful, your new builds work nicely...

FWIW you mentioned that you use a patch by Sherpya for your builds. Sherpya's FFmpeg builds used to be XP compatible on my ancient XP machine, but not any more. His latest build from June 2020 crashes right on startup with the same error popup as your build before the fix.

Looks like for XP users your builds are now the only game in town...

[StainlessS]

Big up to Reino, thanks very much https://www.cosgan.de/images/smilie/froehlich/k020.gif

[real.finder]

your build remind me of this (https://oss.netfarm.it/mplayer/)

btw, is build for xp mean remove some of the features from ffms2 and ffmpeg? or they the same as non-xp one?

[Reino]

[Sherpya's] latest build from June 2020 crashes right on startup with the same error popup as your build before the fix.The "avcodec: Add MediaFoundation encoder wrapper (https://github.com/FFmpeg/FFmpeg/commit/050b72ab5ef318605b305aa6cb920e8b52f1002e)"-commit is from 19 May 2020 and his -buildconf doesn't contain --disable-mediafoundation, so that's probably why.
Just like my own binaries before the fix, for me Sherpya's 'ffmpeg.exe' doesn't crash upon simply invoking ffmpeg.exe, BUT does crash the moment I use -c:v libx264.
According to his source (https://github.com/sherpya/mplayer-be/blob/master/config.sh) (see "GLOBAL_CFLAGS") he does compile FFmpeg for non-SSE2 cpus, so I don't know what causes this crash.

A bit off-topic, but what puzzles me is how relatively small his binaries are. His 'ffmpeg.exe' has more components/libraries on board and is even compiled with --enable-hardcoded-tables (which if I'm correct increases filesize), but is still ~18MB smaller than mine. :confused:
is build for xp mean remove some of the features from ffms2 and ffmpeg? or they the same as non-xp one?From the top of my head... libx265 doesn't support high bit-depth, but apart from that everything is the same. Only made compatible for WinXP and non-SSE2 cpus.

[qyot27]

From the top of my head... libx265 doesn't support high bit-depth, but apart from that everything is the same.
It's not that it can't, it's that you have to use -DENABLE_ASSEMBLY:bool=off to enable 10 and 12 bit on i686 (which also means encoding to those bit depths will be slow as molasses, but it can be done). Nothing to do with XP.

[Reino]

I know that libx265 supports high-bit-depth. I should've chosen my words more carefully. What I meant was: the libx265 that's part of my FFmpeg binary doesn't support high-bit-depth, because...

http://hg.videolan.org/x265/file/tip/source/CMakeLists.txt (http://hg.videolan.org/x265/file/tip/source/CMakeLists.txt):
if(X64)
# NOTE: We only officially support high-bit-depth compiles of x265
# on 64bit architectures. [...]
[...]
endif(X64)

[Reino]

I've just uploaded new binaries. That is, only a static build for FFmpeg so far.

Running configure (while trying to compile a shared build) went just fine, but not with make. This is the short log:
GEN libavutil/libavutil.version
GEN libswscale/libswscale.version
GEN libswresample/libswresample.version
GEN libpostproc/libpostproc.version
GEN libavcodec/libavcodec.version
GEN libavformat/libavformat.version
GEN libavfilter/libavfilter.version
GEN libavdevice/libavdevice.version
CC libavdevice/alldevices.o
CC libavdevice/avdevice.o
CC libavdevice/dshow.o
CC libavdevice/dshow_common.o
CC libavdevice/dshow_crossbar.o
CC libavdevice/dshow_enummediatypes.o
CC libavdevice/dshow_enumpins.o
CC libavdevice/dshow_filter.o
CC libavdevice/dshow_pin.o
CC libavdevice/gdigrab.o
CC libavdevice/lavfi.o
CC libavdevice/reverse.o
CC libavdevice/sdl2.o
CC libavdevice/utils.o
CC libavdevice/vfwcap.o
WINDRES libavdevice/avdeviceres.o
/bin/sh: /cygdrive/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc -E -xc-header
-DRC_INVOKED -MMD -MF libavdevice/avdeviceres.d -MT libavdevice/avdeviceres.o: No such file or directory
/cygdrive/m/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-windres: preprocessing failed.
make: *** [ffbuild/common.mak:93: libavdevice/avdeviceres.o] Error 1
If anyone knows what's going on and knows how to fix it, I'd really appreciate it.

About the static FFmpeg build; thanks to Stephen Douglas the x265 library is now multi-bit-depth:
ffmpeg.exe -hide_banner -h encoder=libx265
Encoder libx265 [libx265 H.265 / HEVC]:
General capabilities: delay threads
Threading capabilities: other
Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p gbrp
yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le
yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le
[...]

[patul]

WINDRES libavdevice/avdeviceres.o
/bin/sh: /cygdrive/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc -E -xc-header
-DRC_INVOKED -MMD -MF libavdevice/avdeviceres.d -MT libavdevice/avdeviceres.o: No such file or directory
/cygdrive/m/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-windres: preprocessing failed.
make: *** [ffbuild/common.mak:93: libavdevice/avdeviceres.o] Error 1

Perhaps windres.exe (part of binutils) was the problem, maybe you can try to use previous working version?

[manolito]

I've just uploaded new binaries. That is, only a static build for FFmpeg so far.

Thanks... :D:D:D
Works here without any issues.

[FranceBB]

Thanks for the new build, hugely appreciated! ;)

[Reino]

Perhaps windres.exe (part of binutils) was the problem, maybe you can try to use previous working version?
Too late I noticed "windres error with binutils 2.36.1 (https://github.com/rdp/ffmpeg-windows-build-helpers/issues/554)" and the suggested fix (https://github.com/rdp/ffmpeg-windows-build-helpers/pull/558/files), because I had already started a complete re-run with binutils 2.35.2.
Anyway, going back to 2.35.x proved successful. Thanks.

I've just uploaded new ffmpeg binaries and removed the "old" static one.

[FranceBB]

Thanks! :D
Any plan for a new build of ffms2 as well?
(I'm not in a hurry, just saying. And by the way, thank you so much for keeping the project updated and XP compatible).

[Reino]

Seeing there are no new commits (https://github.com/qyot27/ffms2_cplugin/commits/c_plugin) since my last build, I wasn't about to.

[FranceBB]

Ah, right, so nothing changed, I see...
Well, that's fine then. :)

[manolito]

@Reino

could you have a look at this post:
https://forum.doom9.org/showthread.php?p=1943204#post1943204

[GMJCZP]

I'm testing version 4.5 static and it doesn't have the -preme argument (Estimation of previous movement) than if you have another videohelp build, the 4.2 static. Did they remove -preme?

[Reino]

I have no idea what you're talking about. Are you sure you posted in the right topic?

[GMJCZP]

In my signature I have a script based on FFMpeg to encode files to DVD. I downloaded the latest version and noticed that the -preme argument does not recognize it, my doubt is that the folks at FFMpeg removed -preme from their compilations.

Reino, or could it be that when compiling you skipped -preme?

[lvqcl]

https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/d85c41b5723a4acf9400043cb533682d2e2c4287#patch3

avcodec: Remove private options from AVCodecContext


-#if FF_API_PRIVATE_OPT
- /** @deprecated use encoder private options instead */
- attribute_deprecated
- int pre_me;
-#endif

[GMJCZP]

https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/d85c41b5723a4acf9400043cb533682d2e2c4287#patch3

avcodec: Remove private options from AVCodecContext


-#if FF_API_PRIVATE_OPT
- /** @deprecated use encoder private options instead */
- attribute_deprecated
- int pre_me;
-#endif

Thanks, but I downloaded a version shared from Here (https://github.com/sudo-nautilus/FFmpeg-Builds-Win32/releases/tag/autobuild-2021-06-27-12-28) and is present -preme.

[Reino]

Apart from a couple of patches to make ffmpeg WinXP compatible again, I haven't removed functionality. At least, not that I know of.

[GMJCZP]

Don't worry Reino, I suspect that preme was removed due to optimizations in the same encoding. I did a quick test and did not notice practically any major difference, so an increase in speed has apparently been gained, I say apparently because this increase may also be due to general optimizations.

[nevcairiel]

The option is still available in newer FFmpeg, it just changed its name - the global option was removed, and the codec-specific one for mpeg remains. So for this particular option, try "-mepre" instead

[GMJCZP]

The option is still available in newer FFmpeg, it just changed its name - the global option was removed, and the codec-specific one for mpeg remains. So for this particular option, try "-mepre" instead

Thanks for the clarification, I have confirmed the information.

[Reino]

I wanted to release new FFmpeg binaries, but I'm having difficulty creating error-free binaries. I need some more time, if I can fix it at all. "When it's done", I guess. :(

[FranceBB]

No worries, there's no rush. :)

[Reino]

A couple of headaches later...
Earlier this evening I've uploaded new binaries. Changelog in post #1 as usual. And my Github repo is already up-to-date as well.

At first libass its DirectWrite implementation caused a compilation-error (https://github.com/Reino17/ffmpeg-windows-build-helpers/commit/bedd85a5647def711207d02a0eebbc00e0e6a3a5).
Next a successfully compiled FFmpeg binary crashed immediately with the Windows error-message "The procedure entry point InitializeConditionVariable could not be located in the dynamic link library KERNEL32.dll".
Doing a search for "InitializeConditionVariable" among the compiled and installed libraries returned:
[...]/i686-w64-mingw32/lib/libwebp.a
[...]/i686-w64-mingw32/lib/libx265.a
For further testing I've compiled FFmpeg without --enable-libwebp and --enable-libx265, but it now crashed with the Windows error-message "The procedure entry point K32GetProcessMemoryInfo could not be located in the dynamic link library KERNEL32.dll".
Lots of searching and reading and through https://www.mingw-w64.org/changelog (https://www.mingw-w64.org/changelog) I landed at...

https://sourceforge.net/p/mingw-w64/mailman/message/37287751 (https://sourceforge.net/p/mingw-w64/mailman/message/37287751):
_WIN32_WINNT is now set to Windows 10 as default.

I had updated Zeranoe's "MingGW-w64 Build Script" (https://files.1f0.de/mingw/scripts) to r32, which uses MingGW-w64 9.0.0. Reverting MingGW-w64 to 8.0.2 (https://github.com/Reino17/ffmpeg-windows-build-helpers/commit/b1d4257c11a61df7876e58990b0952f380406a29) resolved all errors.

The strange thing is that, unlike 'libwebp.a', 'libx265.a' still contains "InitializeConditionVariable" (a function not available on WinXP), but using -c:v libx265 seems to work just fine (so far).

I'm not a coder by profession, so I was wondering if anyone knows if MingGW-w64 9.0.0 contains some sort of WinXP compatible configuration option to correctly set "_WIN32_WINNT". Or would patching be required?

[LoRd_MuldeR]

I'm not a coder by profession, so I was wondering if anyone knows if MingGW-w64 9.0.0 contains some sort of WinXP compatible configuration option to correctly set "_WIN32_WINNT". Or would patching be required?
You #define _WIN32_WINNT (or set it via -D_WIN32_WINNT command-line option) to specify the version of Windows NT that you are targeting.

And you have to do this before #include'ing the <Windows.h> header file, or before #include'ing anything that implicitly #include's the <Windows.h> header file – otherwise it will have no effect at all!

Anyways, all that _WIN32_WINNT really does is to enable/disable the declaration of certain Win32 API functions (in the header file, and only there), depending on whether they were available in the target Windows version.

It does not "magically" change the application code! So, if the code that your are compiling depends on a certain Win32 API function, but that function is disabled via _WIN32_WINNT, then the compilation is going to fail :rolleyes:


Also note that _WIN32_WINNT does not effect the pre-compiled libraries (.a files), which you are linking, in at all! That's because _WIN32_WINNT has to be used at compile-time, not at link time!

If you want to change the target Windows version of a library (.a file), then you have to re-compile that library from the sources and correctly set _WIN32_WINNT while doing so.

For the same reason, setting _WIN32_WINNT has no effect on MinGW-w64 itself or any of the pre-compiled libraries that ship with MinGW-w64. It may have an impact, if you build MinGW-w64 yourself, from the sources.


Last but not least, latest MinGW-w64 still can (https://sourceforge.net/projects/muldersoft/files/cURL/curl-windows-x86.2021-06-20.zip/download) produce binaries that run on Windows XP, i.e. MinGW-w64's own runtime apparently doesn't use any Win32 API functions that weren't available in Windows XP.

But: That does not apply to libwinpthread, i.e. the implementation of the pthread-API that comes with MinGW-w64. Obviously, libwinpthread uses Win32 API functions only available on Vista and higher – and there's not much you can do about that. Consequently, as soon as the application code (or any of the dependencies that you are linking in) uses multi-threading via the pthread-API, then the resulting binary won't run on Windows XP. At least when using libwinpthread.


As an aside: Dependency Walker (https://www.dependencywalker.com/) (or, on modern Windows versions: Dependencies (https://github.com/lucasg/Dependencies) by lucasg) is your friend! ;)

[Reino]

(or set it via -D_WIN32_WINNT command-line option)Which I assume is a cmake option?

It does not "magically" change the application code! So, if the code that your are compiling depends on a certain Win32 API function, but that function is disabled via _WIN32_WINNT, then the compilation is going to fail :rolleyes:Then I might as well stick to MingGW-w64 8.0.2 from now on to save myself lots of trouble.

Also note that _WIN32_WINNT does not effect the pre-compiled libraries (.a files), which you are linking, in at all! That's because _WIN32_WINNT has to be used at compile-time, not at link time!I don't use pre-compiled libraries. I compile everything myself, because not only do the binaries that I compile need to be WinXP compatible, they need to work on old non-SSE2 cpus as well.

If you want to change the target Windows version of a library (.a file), then you have to re-compile that library from the sources and correctly set _WIN32_WINNT while doing so.Yes, I understand I have to re-compile all dependency libraries in that case.

For the same reason, setting _WIN32_WINNT has no effect on MinGW-w64 itself or any of the pre-compiled libraries that ship with MinGW-w64. It may have an impact, if you build MinGW-w64 yourself, from the sources.Which I do, as I'm using Zeranoe's "MingGW-w64 Build Script" after all.

But: That does not apply to libwinpthread, i.e. the implementation of the pthread-API that comes with MinGW-w64.The reason why I'm compiling MinGW-w64 with pthreads-w32 (which is the default thread library in Zeranoe's "MingGW-w64 Build Script" anyway).

Thanks for your elaborate post, LoRd_MuldeR.

[LoRd_MuldeR]

Which I assume is a cmake option?

It's an option for GCC. Or any compiler with GCC-compatible command-line syntax, such as Clang. You generally add this to the CFLAGS (https://en.wikipedia.org/wiki/CFLAGS), or whatever is the equivalent in cmake.

Then I might as well stick to MingGW-w64 8.0.2 from now on to save myself lots of trouble.

Don't know how this would save you from trouble.

If the code of the application (or its dependencies) that you are compiling uses some function from the Win32 API that was not yet available in Windows XP, then it won't be able to run on Windows XP – regardless of which version of MingGW-w64 you are using to build. Even setting _WIN32_WINNT to 0x0501 won't "magically" make the code run on Windows XP; this only causes the compilation to fail, if the code attempts to call a function that was unavailable in Windows XP.

Only way to get the application (or library) work on Windows XP will be to "patch" the actual program code in order to remove/replace any invocation of the "problematic" Win32 API functions...

[manolito]

Hi Reino,

long time no see, and you are no longer too active in the forum. I have been away for more than a year now due to a stroke. I try to relearn a few of my computer skills, but it is tough...

Back to your FFMpeg builds:
The version I have installed is still v. 4.5 from May 2021, and it works nicely. Now I noticed that you published new versions, the current one is v. 5.2. So I wonder if I should update. I do not think that I really need any new FFMpeg features, I am more interested in bug fixes and other improvements.

I made a short conversion using the current version 5.2, and everything seemed to work well, but I am a little reluctant to jump on the latest and greatest without asking for possible catches. As I already said, I am not looking for new FFmpeg features, I just like to take advantage of possible improvements and fixes of existing features.

I also have to say that in the past I did have some bad experiences with using new major FFMpeg versions too soon before they had time to mature. Maybe it would be safer to continue using the final 4.5 version for now?

Cheers
manolito

[Reino]

you are no longer too active in the forum.Yes. Too little time and other interests, I guess. From time to time I do still read threads of interest though.
I have been away for more than a year now due to a stroke.I'm sorry to hear that.
So I wonder if I should update. I do not think that I really need any new FFMpeg features, I am more interested in bug fixes and other improvements.In that case I think you should. I haven't enabled any extra external libraries in my FFmpeg binaries, so I think bug fixes and other improvements (upstream) is exactly what you can expect.

[manolito]

Thanks for your advice, much appreciated...

I made a couple of more tests under Win7 using your latest version 5.2 together with libfdk, no problems whatsoever. Still need to test if my ancient WinXP machine also likes version 5.2.

Thanks again
manolito

[metis]

@LoRd_MuldeR
Only way to get the application (or library) work on Windows XP will be to "patch" the actual program code in order to remove/replace any invocation of the "problematic" Win32 API functions...
This means Revising - and, if necessary, Modifying :scared: - the entire FFmpeg-SourceCode and the Sources of all Dependencies, that
link to the actual FFmpeg-Build - Phew, that's really a lot of Work !


@manolito
Still need to test if my ancient WinXP machine also likes version 5.2.
I just tried it on my WinXP 32-bit SP3...

I use the FFmpeg-DLLs in my FFPlay4Laz-Project, which is an ultrafast FFmpeg-based MediaPlayer/-PlayerEngine with
outstanding AudioQuality via PortAudio (www.portaudio.com) and ASIO (and some other "unusual" Features):
https://forum.lazarus.freepascal.org/index.php/topic,26666.msg428667.html#msg428667
This is the latest Release - The next Release will use Reino's WinXP-compatible Build for FFmpeg v5.2 to keep that Player
Running from WinXP to Win10 w/o any Modifications. :)

The FFmpeg-CLIs are required by 'RunFFmpeg', which is Part of my FFGrab4Laz-Project:
https://forum.lazarus.freepascal.org/index.php/topic,43411.0.html
-> GoTo "RunFFmpeg".
This is the OpenSource-BasicStructure for an ALL-In-One-GUI for any FFmpeg-Task, like
ScreenRecording, Converting, Playback/Streaming, Ripping/Recording, ... endless.
Everyone may extend and modify it to his personal Needs.

I tried both with Reino's shared Builds for FFmpeg v4.2 + v5.1 + v5.2, and they work all perfectly.
The DEVs I tried with Code:Blocks v17.12/gcc v5.1.0 (32-bit) - They work fine, as well.


@Reino
Which OS do You use for Your WinXP-compatible FFmpeg-Builds ?

Formerly, I used the FFmpeg-Builds from FFVCL (http://www.delphiffmpeg.com/downloads/) or I've built them myself.
But, this no longer works on my WinXP with newer FFmpeg-Versions (:(). So I am very glad, that I found your WinXP-Builds.
Many Thanks for your Work from all, who cannot be w/o their beloved WinXP-Machines (like me :) ).