JPSDR Avisynth's plugins pack

[jpsdr]

New version, see first post.

[FranceBB]

I love seeing HDRTools_AVX512_asm_x64.asm and nnedi3_asm_AVX512_x64.asm in there.
Manually written assembly in AVX512 for tonemapping and NNEDI3 feels like a dream. :D
I gotta perform some benchmarks now, but thank you so much for this, Jean Philippe!

By the way, I've updated the wiki to reflect the changes http://avisynth.nl/index.php/Nnedi3/nnedi3_rpow2 as int opt = 0 can now go all the way up to 8 rather than 7.


int opt = 0
Sets which CPU optimizations to use. Possible settings:
0 = auto detect
1 = use C
2 = use SSE2
3 = use SSE4.1
4 = use AVX
5 = use AVX2
6 = use FMA3
7 = use FMA4
8 = use AVX512


as per https://github.com/jpsdr/plugins_JPSDR/commit/fce98309da3aa1942852dad7f66e3b115c75934a and https://github.com/jpsdr/plugins_JPSDR/blob/30f87b61016a4c15218e4b507fcd57803b632cd2/Plugins_JPSDR/nnedi3.cpp#L469

[jpsdr]

For tonemapping, i've updated to AVX512 the AVX2 code, and there is very few things finaly in the AVX2.
... I just realized that maybe because a lot of things where either lookup table or float, if there is so few AVX2 maybe it's because a lot of things are AVX, as YMM float registers and functions are AVX not AVX2...
I'll have to check this and maybe the asm AVX512 will grow bigger... :D
For now, there is only Convert_16_RGB64_HLG_OOTF and BT2446C_16_XYZ, almost nothig.
Wait another release if you want to benchmark tonemap, but NNEDI3 is good to go. I've updated everything i could (some are left AVX2 because i didn't understood properly and wasn't sure), but the core and the most important is done.

[jpsdr]

New version, see first post.

[jpsdr]

New version with a newcommer, see first post.

[FranceBB]

The XP build of v4.0 isn't working on Windows XP Professional x86 as it's missing InitializeCriticalSectionEx and LCMapStringEx.
XP has InitializeCriticalSection and LCMapStringA but not the Ex version as those were introduced with Windows Vista.
https://i.imgur.com/YyD8ljf.png


Reverting to version 3.9 works and doesn't show any issues in Dependency Walker.
https://i.imgur.com/b9GdBl2.png
https://i.imgur.com/PshNyOZ.png

[jpsdr]

Ah... I'm not sure i'll be able to fix this, as i didn't change anything in the compiler options... Except maybe allowing C++17... And i'm not even sure about this.
I'll check...

Edit:
I don't have an XP to test, are the following working ?
- The JincResizeMT release.
- The last ResampleMT release.

Edit2:
This feedback may help me to figure out, for now i have no idea why it suddenly changes, as i didn't change the compiler neither the options... :(

[FranceBB]

I've made a few tests and it turns out it's related to JincResize.
I went to asd's repository and re-compiled the original JincResize with v141_xp and /Zc:threadSafeInit- using Visual Studio 2022.
Unfortunately that didn't help and it still didn't run.
In other words, the culprit seems to be JincResize, but I can't figure out *what* in JincResize is causing this. :(

[DTL]

Try to disable OpenMP in compiler settings. Also you need old enough version used OpenMP instead of new C++ multithreading. Or you can test even more old version without internal multithreading (no threads param).

[jpsdr]

@FranceBB
Thanks for testing. I had a guess it could be JincResizeMT as it was the big new change, but without being sure.
I've pushed a small update on JincResizeMT, if you can do the following tests on what i've pushed:

Step 1 :
On both JincResizeMT.cpp and resize_plane_avx2.cpp comment #include <cmath> and #define C17_MATH_ENABLE.
Build, test. If issue is solved, stop here.

Step 2 :
On JincResizeMT.cpp comment #define AVX512_BUILD_POSSIBLE and on resize_plane_avx512.cpp replace #if _MSC_VER >= 1911 with #if 0
Build, test. If issue is solved, stop here.

Step 3 :
On JincResizeMT.cpp comment #define AVX2_BUILD_POSSIBLE and on resize_plane_avx2.cpp replace #if _MSC_VER >= 1800 with #if 0
Build, test.

[DTL]

Also about multithreading settings at C compiler may be tested 2 ways:
C Runtime Library Selection:

/MD (Multi-threaded DLL):
This option links your DLL with the multithread-specific and DLL-specific version of the runtime library (e.g., MSVCRT.lib for release, MSVCRTD.lib for debug). This is generally the recommended approach for DLLs as it allows sharing a single instance of the CRT across multiple modules.
/MT (Multi-threaded):
This option links your DLL with a static version of the multithreaded runtime library (LIBCMT.lib). While possible, it can lead to issues if the executable using the DLL is linked with a different CRT version, potentially causing problems with memory allocation or file handles.

CriticalSections is something around threads synchronization in multithreading and usage these .dlls may depend on the used multithreading options in the executable.

[jpsdr]

/MT locks you with the version of redistributable linked.
/MD allow user to update the version of redistributable, so i'm using it, except for the XP release to be sure the version is XP compatible.

[FranceBB]

Try to disable OpenMP in compiler settings.

Done and tested. By the way, I always build with /MT as I prefer to statically link instead of using whatever C++ Redistributable is installed as I find it easier to debug.

Anyway, this led me to the following test where test 0 is DTL's suggestion while test 1 to 3 are Jean Philippe's suggestions.

Mini spoiler: all of them work on XP. :D
In other words, the culprit was OpenMP, which is why adding /openmp- did the trick. :)

Test 0:
v141_xp /openmp- /Zc:threadSafeInit-
code as is

XP x86 Build: JincResizeMT_Test0_x86.dll (https://github.com/FranceBB/JincResizeMT/releases/download/1.1.0.0/JincResizeMT_Test0_x86.dll)

https://i.imgur.com/RNgP8en.png
https://i.imgur.com/1MoIAyx.png

Test 1:
v141_xp /openmp- /Zc:threadSafeInit-
JincResizeMT.cpp

//#include <cmath>
//#define C17_MATH_ENABLE

resize_plane_avx2.cpp

//#include <cmath>
//#define C17_MATH_ENABLE

XP x86 Build: JincResizeMT_Test1_x86.dll (https://github.com/FranceBB/JincResizeMT/releases/download/1.1.0.0/JincResizeMT_Test1_x86.dll)

https://i.imgur.com/PalRhnW.png
https://i.imgur.com/WQJ3Zx1.png

Test 2:
v141_xp /openmp- /Zc:threadSafeInit-
JincResizeMT.cpp

//#include <cmath>
//#define C17_MATH_ENABLE
//#define AVX512_BUILD_POSSIBLE
resize_plane_avx2.cpp

//#include <cmath>
//#define C17_MATH_ENABLE

resize_plane_avx512.cpp

#if 0


XP x86 Build: JincResizeMT_Test2_x86.dll (https://github.com/FranceBB/JincResizeMT/releases/download/1.1.0.0/JincResizeMT_Test2_x86.dll)

https://i.imgur.com/XvDbTMV.png
https://i.imgur.com/knCcUy6.png

Test 3:
v141_xp /openmp- /Zc:threadSafeInit-
JincResizeMT.cpp

//#include <cmath>
//#define C17_MATH_ENABLE
//#define AVX512_BUILD_POSSIBLE
//#define AVX2_BUILD_POSSIBLE

resize_plane_avx2.cpp
//#include <cmath>
//#define C17_MATH_ENABLE
#if 0
resize_plane_avx512.cpp

#if 0


XP x86 Build: JincResizeMT_Test3_x86.dll (https://github.com/FranceBB/JincResizeMT/releases/download/1.1.0.0/JincResizeMT_Test3_x86.dll)

https://i.imgur.com/EYiEeIb.png
https://i.imgur.com/aKzpNex.png

[jpsdr]

Ok. When back home, I'll check in my project configuration if OpenMP is enabled for XP builds. If it is, i'll disable it, and culprit is found also on my side.

[StainlessS]

@FaBB,

In UK, all I get is "Content Not viewable in you region" for your images [not just in this thread, all over the place recently].

[You still in "Royal Borough of Kensington & Chelsea, UK" ???]

[FranceBB]

Ok. When back home, I'll check in my project configuration if OpenMP is enabled for XP builds. If it is, i'll disable it, and culprit is found also on my side.

Ok, thank you. :)


In UK, all I get is "Content Not viewable in you region" for your images [not just in this thread, all over the place recently].

[You still in "Royal Borough of Kensington & Chelsea, UK" ???]

I am, but I'm using a VPN to "pretend" to be in the U.S.
Until Labours are gonna ban those as well to "protect the children", that is.

I'm gonna quote myself from the other post


p.s for those in the UK, if you can't see the images, it's because of Captain Hindsight's online safety bill as imgur is no longer available and yet another service caught in the crossfire. Say thanks to Labours and Sir Keir Starmer I guess.

This is a problem 'cause I've been using imgur to host all my pictures since 2013. Migrating all of those is gonna be extremely painful. And yes, when I'm at work and I'm using the real IP address I also get the "not available in your region" message of course. At home I've set up a router with OpenWRT (i.e a linux distro for routers) that offers a VPN via Wireguard to all my devices connected to the Wi-Fi. It also exposes a separate Wi-Fi network that uses my real IP when I have to connect to the BBC iPlayer, ITV, Channel 5 etc.

[DTL]

It looks openmp support left enabled from the old times of JincResize plugin in Asd-g repository - https://github.com/jpsdr/JincResizeMT/blob/841f9a78ec55b098927d09aa561745eadff05659/JincResizeMT/JincResizeMT.vcxproj#L144 . New versions do not use it.

[jpsdr]

@FranceBB
It's odd... OpenMP was enabled in my ResampleMT and JincResizeMT projects, but not in plugin_jpsdr project. So either i've build plugin_jpsdr with OpenMP and disabled it since, or there is still something else.
Can you PM me an email address i can send you XP build, to be sure ? The one i have seems to be not working anymore.

[FranceBB]

Can you PM me an email address i can send you XP build, to be sure ?

I sent you a message, but if you want you can just upload the build anywhere on your FTP and I'll grab it from there (my login still works). ;)

[jpsdr]

Done on FTP, forgot you had this one.
Tell me when retrieved and test result.

[FranceBB]

Done on FTP, forgot you had this one.
Tell me when retrieved and test result.

Unfortunately it's not working.
It's complaining about the following two kernel calls missing:

LCMapStringEx
InitializeCriticalSectionEx

same as before.
Are you absolutely sure that you used /openmp- /Zc:threadSafeInit- in v141_xp?


In my other tests:

- HDRTools v1.2.0 -> ok
- NNEDI3 v.0.9.4.67 -> ok
- AutoYUY2 v.4.1.11 -> ok
- aWarpSharpMT v.2.1.11 -> ok
- ResampleMT v.2.9.0 -> error

So it has to be ResampleMT due to JincResize, but we solved JincResize, so...

[jpsdr]

Are you absolutely sure that you used /openmp- /Zc:threadSafeInit- in v141_xp?

Yes, i've checked them before building.
/Zc:threadSafeInit- is present in XP builds since the begining of times, and in "langage" in the projet i have "Disable OpenMP", which produces /openmp-.
I'm not able to figure out what have changed in the project settings since the last build, as I don't remember even doing modifications in the project settings (don't remember doesn't mean not doing...).

And JincResizeMT is not in ResampleMT, but both had OpemMP.

Can you compress/7z your whole (cleaned up before) project and put it on the FTP ? (You have write access, but not delete).
I'll try to open it and check if i can figure out the differences. What Visual Studio version are you using ?

[jpsdr]

@FranceBB
I will, not right now, but soon, make a new release (as there was some JincResizeMT changes), so if you have time within the next days to compress/7z your whole (cleaned up before) project and put it on the FTP, this will allow me to check vs my project, and maybe figure out what setting creates the problem.

[FranceBB]

@FranceBB
I will, not right now, but soon, make a new release (as there was some JincResizeMT changes), so if you have time within the next days to compress/7z your whole (cleaned up before) project and put it on the FTP, this will allow me to check vs my project, and maybe figure out what setting creates the problem.

I've uploaded it to the folder, but that's only JincResizeMT. I've downloaded the latest master of plugins_JPSDR. I'm gonna compile and test in the next few days. If it works, I'll add that one to my folder in the FTP too.

[jpsdr]

Ok, i'll get it when back home this evening. The first thing i'll do, it's just to compile your project without changing anything, to see if it's something related with my PC and not the settings (i hope it's not).
I'll also put my plugins_JPSDR project, for you to check to build without changing anything, to also see if it's related to the settings.
Without changing anything may have an exception, the windows SDK target build, you may have to convert to match your Visual Studio version for the project, but... It shouldn't affect the XP target build, which are to v141_xp, and these shouldn't change even after conversion to match for the rest of the project.

[jpsdr]

@FranceBB
I've tried to build your project, but it failed saying that fabs is not part of std.
I've put on the server, for both plugins_JPSDR and JincResizeMT, my projects.
But i've noticed something.
Can you try to build, in Code generation, with and without QPar ("Parallel code generation") ?

[FranceBB]

I've compiled JincResizeMT with and without QPar and uploaded the .dll to the FTP.
Both builds work and don't have any issues on XP.

[jpsdr]

So, that's not it... :(
Did you use my projects ?

[FranceBB]

Did you use my projects ?

Yep I did. I'll try to compile plugins_JPSDR too next and see how it goes (currently Crowdstrike - yes the bluescreen company - is giving me a hard time on Windows 11 as it keeps blocking random stuff, but I'll try to do it soon).

[jpsdr]

You mean you used my project to build JincResizeMT and it worked ? Good to know ! In that case, this evening when back home i'll put a build of JincResizeMT made by me on the server.
In the meantime, if you can try to build plugins_JPSDR and check, this will allow to assert the following situations :
(a) : Is JincResizeMT working build on your side and on my side ?
(b) : Is plugins_JPSDR working build on your side ?
The "best" case would be that JincResizeMT is working with both build, but plugins_JPSDR don't. That would mean that i've "just" to find the setting there is in one there is not in another which creates the issue.
The worst case would be that when you build my project, it works, and when i build the exact same project, it doesn't. I would have no idea how to solve this case.

[jpsdr]

I've made a build of JincResizeMT on the server for you to test.

[FranceBB]

Unfortunately that didn't work, so we're in the "worst" possible scenario. :(
It's still complaining about InitializeCriticalSectionEx and LCMapStringEx.

Are you also using Visual Studio 2022 to build those or is it an older version?
Perhaps there's some difference in the .sln between the two versions even if the settings are the same?
I really don't know.

[jpsdr]

No, i'm using Visual Studio 2019, my dev PC is Windows 7 x86, so having Visual Studio 2022 is not possible.
What i don't understand also, it's why it "suddenly" stopped to work. I mean, until now, my XP builds were working, and suddenly, they don't.
I'm lost... I'll try chat GPT, without big hope.
Unfortunately for now i don't have a solution, except for you to make your own builds. :(

[jpsdr]

Chat GPT provided me some things to check, i don't know if it will work, i'll check this WE.
In the meantime, when you'll have time, can you do the following when doing your build:
In "Projet property > Linker > Command Line > Additional Options", can you add "/VERBOSE:LIB" ?
Build, and post the result here ?
In the meantime, this evening when back home i'll try (but no big hope) something else.

[DTL]

You may try to install Win XP on a virtual PC software emulation to check builds. Or even try to analyse dependencies with appropriate software.

[jpsdr]

Euh... ... ... ...

[DTL]

It's still complaining about InitializeCriticalSectionEx

Google AI wrote:
Understanding the Issue:
InitializeCriticalSectionEx is a function introduced in later versions of Windows (Vista and newer) as an enhanced version of InitializeCriticalSection. Windows XP does not natively support InitializeCriticalSectionEx. If a Visual Studio project is compiled with a target platform that uses this function, the resulting executable will fail to run on Windows XP, reporting a missing DLL or entry point error related to KERNEL32.dll or similar.

Solution:
To build a Visual Studio project that is compatible with Windows XP and avoids the InitializeCriticalSectionEx error, the following steps are necessary:
Target Windows XP in Project Settings:
Open your project in Visual Studio.
Right-click on the project in Solution Explorer and select "Properties".
Navigate to "Configuration Properties" > "General".
Set "Platform Toolset" to a version that supports Windows XP. For example, v140_xp (Visual Studio 2015) or v120_xp (Visual Studio 2013). If using an older Visual Studio, ensure the target platform is set to Windows XP.
Set "Windows SDK Version" to an older SDK that supports Windows XP, if applicable.
Avoid Modern API Functions:
Review your code for any direct or indirect calls to functions introduced after Windows XP, such as InitializeCriticalSectionEx.
Replace these calls with their older, Windows XP-compatible counterparts. For InitializeCriticalSectionEx, use InitializeCriticalSection instead.
If using third-party libraries, ensure they are also compiled with Windows XP compatibility in mind or use versions that do not rely on newer API functions.

May be current builds uses some other libraries and they try to load that absent function ? But if you dependency check software shows JincResizeMT.dll directly want to load InitializeCriticalSectionEx from kernel32.dll - it mostly probably mean C compiler for some reason really put this call in the JincResizeMT.dll directly.

Also a quick way to check .dll for this function - simply load in the text editor (or better binary file viewer) and check if it have this text string - InitializeCriticalSectionEx .

I download current sources of JincResizeMT and make release builds with VS2019 - x64, x32 Win XP (v141_xp). No one version of .dll have InitializeCriticalSectionEx string and no such string present in the sources. Only InitializeCriticalSectionAndSpinCount.

I download plugins version 4.0.0 and sources and unzip:
InitializeCriticalSectionEx text sequence only found in the Release_XP_XXX folders .dlls . No other builds have it. Strange. Also sources do not have it too. Compiler get somewhere call to (or dependency to load) for InitializeCriticalSectionEx function and add to .dll .

Here is settings for x32 WinXP build in VS2019
https://i.ibb.co/VWcdvbBb/vs2019-settings01.png (https://ibb.co/d0wSQXKX)
Windows SDK for XP builds only available 7.0 or 8.1.

One more possible solution - make a fresh install of VS2019 on a new clean Windows ? In the virtual box PC emulator may be (but it is slow to HDD).

[jpsdr]

Can you do de /VERBOSE:LIB and post your results ?

[FranceBB]

Google AI wrote:


Useless AI slop as always.
One of the good things about Doom9 is that it's free from the slop, I love talking to fellow users like you and Jean Philippe. :)


Compiler get somewhere call to (or dependency to load) for InitializeCriticalSectionEx function and add to .dll .


Yeah, it's definitely the compiler getting it wrong due to some settings 'cause nothing in the actual source code has any issues, which is also why when I made the builds with /openmp- /Zc:threadSafeInit- it worked.


Here is settings for x32 WinXP build in VS2019
https://i.ibb.co/VWcdvbBb/vs2019-settings01.png (https://ibb.co/d0wSQXKX)
Windows SDK for XP builds only available 7.0 or 8.1.


Good idea showing the screen.
Here are mine producing working builds:

https://i.postimg.cc/nzZzKxvZ/2.png

and here's a view of the various menus:

https://i.postimg.cc/sxLsLCZc/1.png



In "Project property > Linker > Command Line > Additional Options", can you add "/VERBOSE:LIB" ?
Build, and post the result here ?


No problem, here:


Build started at 6:37 PM...
1>------ Build started: Project: JincResizeMT, Configuration: Release_XP Win32 ------
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v150\Platforms\Win32\PlatformToolsets\v141_xp\Toolset.targets(39,5)
1>
1>Searching libraries
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1>
1>Finished searching libraries
1> Creating library C:\Users\FranceBB\Desktop\JincResizeMT\JincResizeMT\Build\Release_XP\JincResizeMT.lib and object C:\Users\FranceBB\Desktop\JincResizeMT\JincResizeMT\Build\Release_XP\JincResizeMT.exp
1>
1>Searching libraries
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1>
1>Finished searching libraries
1>Generating code
1>0 of 379 functions ( 0.0%) were compiled, the rest were copied from previous compilation.
1> 0 functions were new in current compilation
1> 0 functions had inline decision re-evaluated but remain unchanged
1>Finished generating code
1>
1>Searching libraries
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1>
1>Finished searching libraries
1>
1>Searching libraries
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\LIBCMT.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\OLDNAMES.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libvcruntime.lib:
1> Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86\libucrt.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\kernel32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\user32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\gdi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\winspool.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\comdlg32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\advapi32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\shell32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\ole32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\oleaut32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\uuid.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbc32.lib:
1> Searching C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\odbccp32.lib:
1> Searching C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcpmt.lib:
1>
1>Finished searching libraries
1>JincResizeMT.vcxproj -> C:\Users\FranceBB\Desktop\JincResizeMT\JincResizeMT\Build\Release_XP\JincResizeMT.dll
1>Done building project "JincResizeMT.vcxproj".
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 6:37 PM and took 05.503 seconds ==========


results also in the FTP.

[jpsdr]

Good tips DTL the hexa search string, it avoid me to bother FranceBB for testing.
Short version, i have multiboot, i tried with the other OS (Win7 x64) having a different VS2019 version, same issue. So a different environment produces the same result. It must be related to my maintenance/update, but don't know which one.

You have like me some .lib not in the 7.1A linked, so it's not this... But maybe...
You have 14.16.27023 when i have 14.29.30133.
And you also have libucrt not from 7.1A, not this one also...

Just made a build with /VERBOSE:LIB of release Windows 7.
This time i see .lib linked to SDK 10, and others to the same 14.29.30133. But the string InitializeCriticalSectionEx is not in the dll, so it's not this.
It's realy odd, and as you build the exact same project than me, it's not something in the settings.
I don't know for now...

[DTL]

Same question at stackoverflow - https://stackoverflow.com/questions/22709094/c-application-built-with-120-xp-toolset-on-windows-xp-initializecriticalsecti But it points to some bugs in some versions of VisualStudio (fixed by Microsoft in some updates). May your VS2019 got some update and it broke compatibility with XP ?

[jpsdr]

It's been several years my VS2019 didn't get an update, and it's just now that suddenly XP builds are not working, on my both OS. So, even if there wasn't a VS2019 update since several years, there is a windows update i've made (redistributable, .NET, ...?) which broke the XP builds on my both OS.
I'm building, recycling old motherboard i have a "Frankeisten" PC, with multi boot Windows 7 x86/x64, Windows 10 x64 and Ubuntu (Ubunto has his own HDD, all the Windows are on another HDD), for spare in case my current PC would have issues.
I had to install VS2022 on the Windows 10 x64, i'll try with it. But as i'm following the same update process on all my PC, there is still a risk i encounter the same issue even on this third option, but maybe not.

[jpsdr]

@FranceBB
Euh... How are you able to build for XP with VS2022 ? It was removed after VS2019...:confused:

Edit:
Maybe i've found it, hidden...

Edit 2:
I don't know what to do, the string InitializeCriticalSectionEx is in the XP DLL i've just build with the VS2022 i just updated... :(.
So, on my third OS, i also have the issue.

[FranceBB]

it's just now that suddenly XP builds are not working

I still think it's somewhat related to the inclusion of JincResize.
Although it can be compiled just fine and it does run on XP, there must be something in the source code that makes your configuration *think* that it needs to call an API in the kernel that it doesn't really need, thus producing non-working builds.

The reason why we haven't seen the issue up until this point is that JincResize wasn't there, so when you were building plugins_JPSDR which grouped together HDRTools, NNEDI3, AutoYUY2, aWarpSharpMT and ResampleMT we didn't have any issues.

I'm sure that if you were to build plugins_JPSDR using HDRTools v1.2.0, NNEDI3 v.0.9.4.67, AutoYUY2 v.4.1.11, aWarpSharpMT v.2.1.11 (i.e the latest for all of them) but an older version of ResampleMT (older than 2.9, so without JincResize) it will produce a working build.

This would prove that the issue has technically always been there but it didn't matter 'cause without JincResize the compiler never produced incompatible builds.

@FranceBB
Euh... How are you able to build for XP with VS2022 ? It was removed after VS2019...:confused:


v141_xp is still there. :)

https://i.postimg.cc/7hcbMC16/image.png

[DTL]

Yes - it is good idea to make test builds of plugins_pack of old version sources before addition of JincResize at current configuration. And if it is working as expected - test addition of JincResize (may be by some parts if possible) to see if it somehow trigger the error with incompatible with WinXP builds. Though support of XP may be dropped long time ago at Microsoft and it may not provide any help with such issues. May be other C compilers can do builds for XP ?

[FranceBB]

May be other C compilers can do builds for XP ?

Maybe, but even MSVC can make XP compatible builds when I made the builds with /openmp- /Zc:threadSafeInit-


I don't know what to do, the string InitializeCriticalSectionEx is in the XP DLL i've just build with the VS2022 i just updated... :(.
So, on my third OS, i also have the issue.

Can you check that in Release_XP when it shows All Options it's set as this:


/MP /GS- /Qpar- /GL /analyze- /W3 /Gy /Zc:wchar_t /Gm-
/O2 /Ob2 /sdl- /Fd"Release_XP\vc141.pdb"
/Zc:inline /fp:precise /D "WIN32" /D "NDEBUG"
/D "_WINDOWS" /D "_USRDLL" /D "JINCRESIZEMT_EXPORTS"
/D "_USING_V110_SDK71_" /D "_WINDLL" /D "_MBCS"
/errorReport:prompt /GF /GT /WX- /Zc:forScope
/GR- /arch:IA32 /Gd /Oy /Oi /MT /openmp- /std:c++17
/FC /Fa"Release_XP" /EHsc /nologo /Fo"Release_XP"
/Ot /Fp"Release_XP\JincResizeMT.pch" /diagnostics:classic


and in Additional Option /Zc:threadSafeInit-

https://i.postimg.cc/tC7VMdjm/image.png

I've uploaded my sln back to the FTP

[jpsdr]

I've just made an XP build of AutoYUY2, the string InitializeCriticalSectionEx is in the DLL produced. I've checked my github, the string is in the 4.1.11, but not in the 4.1.9.
For now, the situation is:
- Should it be Visual Studio 2019 11.31 under Windows 7 x86, Visual Studio 2019 9.26 under Windows 7 x64 or Visual Studio 2022 14.17 under Windows 10 x64, the DLL produced has the string InitializeCriticalSectionEx.
- When FranceBB build the exact same project with Visual Studio 2022, the DLL works (meaning there is not the string).

I've disabled all automatic updates in everything (Windows, Visual Studio, etc...), so all my system updates are manualy done by me. One of them probably broke the XP build between the AutoYUY2 4.1.9 and 4.1.11, but i don't know which one. There had been a few years i didn't update Visual Studio (and Windows 7 also of course), but i regulary update the .NET and redistributables.

I'll check with the pictures.

[jpsdr]

Pictures checked, as i thought, as we are using the exact same project, we have the exact same settings.

Edit:
@FranceBB
You said AutoYUY2 4.1.11 worked in one of your posts... But this one has the string InitializeCriticalSectionEx in it. You are sure it works ? If it is, the presence of the string is not a criteria, as i've checked, it was at least in the DLL since the plugins_JPSDR_v3_5_0 version, didn't go back mre. So if plugins_JPSDR stop working only since 4.0.0, i can't check just using the presence of the string.
As it seems i can't use the presence of the string, i still have to bother you to chek, i've made a v3 JincResizeMT for test, just "in case"...

Also, the same but for the linker, except there is not "Additional Options":

/OUT:"F:\PRG\Visual_2019\JincResizeMT\Build\x64\Release_XP\JincResizeMT.dll" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"F:\PRG\Visual_2019\JincResizeMT\Build\x64\Release_XP\JincResizeMT.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"F:\PRG\Visual_2019\JincResizeMT\Build\x64\Release_XP\JincResizeMT.lib" /DLL /MACHINE:X64 /OPT:REF /INCREMENTAL:NO /PGD:"F:\PRG\Visual_2019\JincResizeMT\Build\x64\Release_XP\JincResizeMT.pgd" /SUBSYSTEM:WINDOWS",5.02" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release_XP\JincResizeMT.dll.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /ASSEMBLYDEBUG:DISABLE /TLBID:1


Edit2:
@FranceBB
I've added on the server several versions for testing, as unfortunately checking the string seems not revelevant.

[FranceBB]

I've added on the server several versions for testing, as unfortunately checking the string seems not revelevant.

Looks like we're going somewhere! :D

JincResizeMT_Test_v3 and JincResizeMT_Test_v4

have the following two entries reported by Dependency Walker
InitializeCriticalSectionEx
LCMapStringEx

as they're missing from the kernel and therefore cause the dll to fail to load with the error:

"Cannot load file JincResizeMT.dll. Platform returned code 127: The specified procedure could not be found"

when using


LoadPlugin("D:\test\JincResizeMT.dll")

ColorBars(1920, 1080, pixel_type="YV24")

JincResizeMT(848, 480)


https://i.postimg.cc/qvq45CxN/image.png


but JincResizeMT_Test_VS2022 is absolutely fine! :D
No errors, no missing kernel calls, everything is green and it loads and executes just fine.

https://i.postimg.cc/NFXpMbtb/image.png


Pictures checked, as i thought, as we are using the exact same project, we have the exact same settings.


Well considering that the builds from Visual Studio 2019 don't work but both you and I produce working builds while compiling with Visual Studio 2022 using the same sln with the same settings, I'd say that this is a bug in Visual Studio 2019. In theory, Visual Studio versions are supported for 10 years of security updates, so 16.11 is still supported until April 2029, however whether they're gonna fix the bug or not is anybody's guess, but I feel like we should report it to MSDN. What do you guys think?



You said AutoYUY2 4.1.11 worked in one of your posts... But this one has the string InitializeCriticalSectionEx in it. You are sure it works ?

Yep, I tested again and it definitely works. As to InitializeCriticalSectionEx, I know that you see it, but when I check with Dependency Walker it says that it's not there, in fact everything is displayed as green.

This is version 4.1.11.0 from August 3rd, 2025.
https://i.postimg.cc/G3DW9xXb/image.png

Checked with CFF Explorer too:
https://i.postimg.cc/J41pmNgH/image.png

No issues in Dependency Walker:
https://i.postimg.cc/Gt99JStt/image.png

No issues loading it and using it in Avisynth via AVSPmod mod:
https://i.postimg.cc/kghCWXKd/image.png

[jpsdr]

I don't know why it suddenly stopped working with VS2019, i've checked back plugins_jpsdr until 3.5.0 (didn't check further), and all the DLLs have the string InitializeCriticalSectionEx in them, but if i remember, you said that it was working until 3.9.0. The VS_2022 DLL version also has the string, but it seems working. So for now, it won't be practical for me to have to use the other PC for the builds, but unless i figure out the "why" (very very unlikely) i'll have to.

And as i'm just searching for the string in the DLL, obviously the fact the string is here doesn't mean the ressource will be called. The only thing sure is that if the string is not here, the ressource won't be called... :D

Edit:
@FranceBB
Everything was build without QPar, when back home this evening, i'll bother you one last time with a VS_2022 build with QPar. I know it changed nothing for you when you tested buiding on your own (both worked), but now, i'm very carefull and want to be sure that my build will work.