Windows XP compatible non-SSE2 FFmpeg binaries

[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.
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 I landed at...

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" to r32, which uses MingGW-w64 9.0.0. Reverting MingGW-w64 to 8.0.2 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]

Originally Posted by Reino

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


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 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 (or, on modern Windows versions: Dependencies by lucasg) is your friend!

[Reino]

Originally Posted by LoRd_MuldeR

(or set it via -D_WIN32_WINNT command-line option)

Which I assume is a cmake option?

Originally Posted by LoRd_MuldeR

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

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

Originally Posted by LoRd_MuldeR

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.

Originally Posted by LoRd_MuldeR

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.

Originally Posted by LoRd_MuldeR

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.

Originally Posted by LoRd_MuldeR

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]

Originally Posted by Reino

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, or whatever is the equivalent in cmake.

Originally Posted by Reino

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]

Originally Posted by manolito

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.

Originally Posted by manolito

I have been away for more than a year now due to a stroke.

I'm sorry to hear that.

Originally Posted by manolito

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 - 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 and ASIO (and some other "unusual" Features):
https://forum.lazarus.freepascal.org...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...c,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 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 ).

[metis]

The next Release will use Reino's WinXP-compatible Build for FFmpeg v5.2

@Reino
Here it the first Release of FFPlay4Laz, that uses Your WinXP-compatible FFmpeg-Build:
https://forum.lazarus.freepascal.org...html#msg464784

[StainlessS]

For Reino and others interested in maintaining XP compatability:

It might seem obvious, but, even if using some later compiler, you should install XP compatible help/docs for XP and pretty much ignore your compiler docs [except on the subject of compiler OR XP compatability],
compiler docs will only doc for latest compiler/OS which of course may not work at all on XP+.

EDIT: Many thanx to Reino and Metis and all other contributers, I no longer have XP machine but like to maintain XP compatability just the same.

[FranceBB]

Originally Posted by StainlessS

For Reino and others interested in maintaining XP compatability:

It might seem obvious, but, even if using some later compiler, you should install XP compatible help/docs for XP and pretty much ignore your compiler docs [except on the subject of compiler OR XP compatability],
compiler docs will only doc for latest compiler/OS which of course may not work at all on XP+.

If you're using MSVC through visual studio etc it's just a matter of including v141_xp during the installation (you have to specifically select it in the c++ tools) and targeting it while building and also include /Zc:threadSafeInit as compiling option. Once you've done that, it's highly likely that the build will effectively run on XP.

[Reino]

Strange. Obviously I'm subscribed to my own thread, but I haven't received any notification e-mails.

@metis, glad to be of help. I'm using (a highly tweaked and slimmed down) WinXP Pro SP3.

I wanted to release another batch of FFmpeg binaries, but I actually came here today to tell that I'm a little stuck.

[metis]

@Reino

I'm using...WinXP Pro SP3.

I also use a nLited WinXP Pro SP3, but only as long as I'am not on the Internet. For the Internet I use Linux Mint.
AFAIK, You can't build FFmpeg w/o InternetConnection, respectively w/o Internet it's quite nerve-wracking
to get all the Files and LIBs which are required during the Build-Process.
So, how do You do Your Builds on WinXP ?
Download all Dependencies before Building, and Compile them all "XP-friendly" ?

I wanted to release another batch of FFmpeg binaries...

Don't worry. I've just finished Updating the FFPlay4Laz-Code to Your latest FFmpeg-Build (= v5.2).
So, there's no hurry - at least not for me.

What would be missing in FFmpeg if You simply omit Python in the Build ?

[Reino]

This is still my every-day-computer, so I'm connected obviously. I don't see a reason why I shouldn't.

Originally Posted by metis

What would be missing in FFmpeg if You simply omit Python in the Build ?

At the moment the latest Mbed TLS 3.3.0 release. I've switched to the Mbed TLS 2.28.2 branch, which, despite some Python 3 warning messages, did compile without errors.
Next weekend I'll have some time to look at this again

[StainlessS]

Originally Posted by FranceBB

it's just a matter of including v141_xp
...
Once you've done that, it's highly likely that the build will effectively run on XP.

Nah, many of the system API calls doc'ed in more current compilers dont exist on XP [I know you use a 'frigged' up XP with VISTA/W7
API extension but not everybody does, and some calls may require W10 API].

Another problem is, if you only use current compiler docs, they may only present info for current systems, and may even say things like
supported from W10+ when in actual fact the call may have been supported since Windows 3.1, so is also misleading.

Above is probably a big part of why support for older systems is dropped, its just tiresome to have to look up multiple sets of docs.
You wanna support XP, then good idea to only [or mostly] use XP docs for API and system calls.

However, for just re-compiling code that was written with XP support in mind, then your reply should be good.

[FranceBB]

Originally Posted by StainlessS

[I know you use a 'frigged' up XP with VISTA/W7
API extension but not everybody does, and some calls may require W10 API].

Speaking of which, I invite everyone to try One Core API on Windows XP, which is essentially the XP version of KernelX for Windows98SE. Thanks to the custom kernel with functions backported from newer version of Windows (currently Vista and 7) it allows programs compiled for newer version of Windows to run on XP natively. Since we leverage a lot on the Wine project (a big fat thank you to the Linux guys working on Wine and ReactOS), if a program runs through Wine on Linux it will almost definitely run on Windows XP with One Core API.

Builds: https://github.com/Skulltrail192/One...aries/releases

Source Code: https://github.com/Skulltrail192/One-Core-Api

The code is open source and we're looking for people to help 'cause we're a tiny community of XP enthusiast and Samuel (who is driving the development) can't do everything on his own, so if any of you is willing to help, feel free to reach out.


Oh and as always, long live to Windows XP.

[Emulgator]

Many thanks for bringing OneCoreAPI to my attention, again.
Software restrictions and requirements have me keeping at least 3 different Win systems running: WinXP32SP3, Win7U64, Win10Pro64.
and I maybe even have to go back to Win98 sooner or later for measurement software.
Very valuable, lets make ends meet.

[j7n]

Unless something has changed recently, One-Core-Api is different from KernelEx. It is a collection of many files from Windows NT6, and for this reason was banned by the copyright police on the other forum. After installation you would no longer have "XP", but a hybrid. KernelEx was very small with only some critical functions implemented.