Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th September 2021, 21:15   #41  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 700
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.
__________________
My hobby website
Reino is offline   Reply With Quote
Old 6th September 2021, 00:22   #42  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,957
No worries, there's no rush.
FranceBB is offline   Reply With Quote
Old 11th September 2021, 23:30   #43  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 700
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:
Code:
[...]/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:
Quote:
_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?
__________________
My hobby website
Reino is offline   Reply With Quote
Old 11th September 2021, 23:59   #44  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,249
Quote:
Originally Posted by Reino View Post
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!
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 12th September 2021 at 01:49.
LoRd_MuldeR is offline   Reply With Quote
Old 13th September 2021, 00:08   #45  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 700
Quote:
Originally Posted by LoRd_MuldeR View Post
(or set it via -D_WIN32_WINNT command-line option)
Which I assume is a cmake option?

Quote:
Originally Posted by LoRd_MuldeR View Post
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.

Quote:
Originally Posted by LoRd_MuldeR View Post
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.

Quote:
Originally Posted by LoRd_MuldeR View Post
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.

Quote:
Originally Posted by LoRd_MuldeR View Post
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.

Quote:
Originally Posted by LoRd_MuldeR View Post
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.
__________________
My hobby website
Reino is offline   Reply With Quote
Old 13th September 2021, 19:58   #46  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,249
Quote:
Originally Posted by Reino View Post
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.

Quote:
Originally Posted by Reino View Post
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...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 13th September 2021 at 20:10.
LoRd_MuldeR is offline   Reply With Quote
Old 8th September 2022, 13:43   #47  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,094
Latest version

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

Last edited by manolito; 8th September 2022 at 15:46.
manolito is offline   Reply With Quote
Old 9th September 2022, 15:56   #48  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 700
Quote:
Originally Posted by manolito View Post
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.
Quote:
Originally Posted by manolito View Post
I have been away for more than a year now due to a stroke.
I'm sorry to hear that.
Quote:
Originally Posted by manolito View Post
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.
__________________
My hobby website
Reino is offline   Reply With Quote
Old 11th September 2022, 12:12   #49  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,094
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
manolito is offline   Reply With Quote
Old 17th November 2022, 13:52   #50  |  Link
metis
Registered User
 
metis's Avatar
 
Join Date: Aug 2022
Location: Spain
Posts: 5
@LoRd_MuldeR
Quote:
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
Quote:
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 ).
__________________
FFmpeg based...
- FFPlay4Laz = FFmpeg+SDL+PortAudio = A highly responsive Lightestweight-Mediaplayer with outstanding Sound
- FFGrab4Laz - RunFFmpeg = A One4All-GUI for various FFmpeg-Tasks

Last edited by metis; 24th November 2022 at 15:53. Reason: Improving the Text
metis is offline   Reply With Quote
Old 22nd December 2022, 19:52   #51  |  Link
metis
Registered User
 
metis's Avatar
 
Join Date: Aug 2022
Location: Spain
Posts: 5
Quote:
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
__________________
FFmpeg based...
- FFPlay4Laz = FFmpeg+SDL+PortAudio = A highly responsive Lightestweight-Mediaplayer with outstanding Sound
- FFGrab4Laz - RunFFmpeg = A One4All-GUI for various FFmpeg-Tasks

Last edited by metis; 26th December 2022 at 14:02.
metis is offline   Reply With Quote
Old 1st January 2023, 09:33   #52  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
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.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 1st January 2023 at 09:57.
StainlessS is offline   Reply With Quote
Old 1st January 2023, 16:08   #53  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,957
Quote:
Originally Posted by StainlessS View Post
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.
FranceBB is offline   Reply With Quote
Old 1st January 2023, 22:04   #54  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 700
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.
__________________
My hobby website
Reino is offline   Reply With Quote
Old 2nd January 2023, 11:21   #55  |  Link
metis
Registered User
 
metis's Avatar
 
Join Date: Aug 2022
Location: Spain
Posts: 5
@Reino

Quote:
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" ?

Quote:
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 ?
__________________
FFmpeg based...
- FFPlay4Laz = FFmpeg+SDL+PortAudio = A highly responsive Lightestweight-Mediaplayer with outstanding Sound
- FFGrab4Laz - RunFFmpeg = A One4All-GUI for various FFmpeg-Tasks

Last edited by metis; 3rd January 2023 at 10:42.
metis is offline   Reply With Quote
Old 2nd January 2023, 23:47   #56  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 700
This is still my every-day-computer, so I'm connected obviously. I don't see a reason why I shouldn't.

Quote:
Originally Posted by metis View Post
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
__________________
My hobby website
Reino is offline   Reply With Quote
Old 3rd January 2023, 02:03   #57  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Quote:
Originally Posted by FranceBB View Post
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.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 3rd January 2023 at 15:10.
StainlessS is offline   Reply With Quote
Old 3rd January 2023, 22:25   #58  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,957
Quote:
Originally Posted by StainlessS View Post
[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.


Last edited by FranceBB; 3rd January 2023 at 22:29.
FranceBB is offline   Reply With Quote
Old 4th January 2023, 13:03   #59  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,598
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.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."
Emulgator is offline   Reply With Quote
Old 5th January 2023, 06:52   #60  |  Link
j7n
Registered User
 
j7n's Avatar
 
Join Date: Apr 2006
Posts: 139
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.
j7n is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 07:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.