InpaintFunc.avs - Different result depending on Avisynth version

[hello_hello]

Here's the entire Info Tool log when I delete everything from the auto-loading plugins folder except for the script loading (mostly) C-Plugins, while preventing the script from loading the new AVSInPaint:

[OS/Hardware info]
Operating system: Windows XP (x86) Service Pack 3.0 (Build 2600)

CPU: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz / Conroe (Core 2 Duo)
MMX, SSE, SSE2, SSE3, SSSE3
2 physical cores / 2 logical cores


[Avisynth info]
VersionString: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
VersionNumber: 2.60
File / Product version: 2.6.0.6 / 2.6.0.6
Interface Version: 6
Multi-threading support: No
Avisynth.dll location: C:\WINDOWS\system32\avisynth.dll
Avisynth.dll time stamp: 2015-03-31, 06:40:58 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files\AviSynth\plugins


[Scripts (AVSI)]
C:\Program Files\AviSynth\plugins\Audio Load Additional Plugins.avsi [2019-06-27]

When it's loading the new AVSInPaint:

Not An Avisynth 2 C Plugin: C:\Program Files\AviSynth\C Plugins\AVSInPaint 1.1.dll
(Audio Load Additional Plugins.avsi, line 23)

[pinterf]

I'm seeing the problem. I'll have to look into it.
(And I confused you, the old dll was a 2.5 C DLL as well, avsinfo is listing it as such)

EDIT
Seems, my build has
_avisynth_c_plugin_init@4
while the old dll exports
avisynth_c_plugin_init@4

[hello_hello]

Thanks pinterf!

[pinterf]

Test build for avs 2.6, 32 bit-only, please try if it works and do further test with it.
https://drive.google.com/open?id=1PJctY3PM8avwPY7WomfzuX984OJBDQ_M

[hello_hello]

Test build for avs 2.6, 32 bit-only, please try if it works and do further test with it.
https://drive.google.com/open?id=1PJctY3PM8avwPY7WomfzuX984OJBDQ_M

If you mean the test build doesn't work with Avisynth+, then I can confirm that. :)

Avisynth 2.6.... I haven't run any full encodes, but it's working with my test script. The three InPaintFunc modes seem fine (no crashes or errors so far, anyway).

Cheers.

PS Tested on XP.

[pinterf]

If you mean the test build doesn't work with Avisynth+, then I can confirm that. :)

Avisynth 2.6.... I haven't run any full encodes, but it's working with my test script. The three InPaintFunc modes seem fine (no crashes or errors so far, anyway).

Cheers.
Then we are halfways :)

What is searched for when establishing from a DLL if it is a C plugin?

AVS+ x64:
avisynth_c_plugin_init
_avisynth_c_plugin_init@4

AVS+ Win32
_avisynth_c_plugin_init@4
avisynth_c_plugin_init@4

AVS 2.6 Win32
avisynth_c_plugin_init@4
avisynth_c_plugin_init

So the winner is: avisynth_c_plugin_init@4 that works for both Avs+ and Avs 2.6

Since the old AvsInpaint.dll exports avisynth_c_plugin_init@4 there is no problem.

Now my question: how on Earth can I remove the underscore and keep the parameter length (@4) in a Visual Studio build?

[Gser]

Moved to git, real release:
AvsInPaint v1.1 (20190624)
https://github.com/pinterf/AvsInpaint/releases


- Fix crash in AVSInpaint-2008.02.23, when using mode "Deblend" or "Both"
(double frame release, revealed when using Avisynth+)
- Add version resource
- Visual Studio 2019 solution
- Moved to Avisynth C 2.5 interface
- x64 version
- (no new colorspaces)

Nice, now I can use rm_logo in x64 avisynth. Thanks!

[hello_hello]

Now my question: how on Earth can I remove the underscore and keep the parameter length (@4) in a Visual Studio build?

I hope you're not asking me?? :)

[qyot27]

Now my question: how on Earth can I remove the underscore and keep the parameter length (@4) in a Visual Studio build?
So it does appear that yes, there's name decoration issues with MSVC building C plugins. Fun.

https://social.msdn.microsoft.com/Forums/vstudio/en-US/6de01933-4855-425c-98cd-8e89487954bc/eliminate-leading-underscore-of-calling-convention-stdcall?forum=vclanguage

[pinterf]

So it does appear that yes, there's name decoration issues with MSVC building C plugins. Fun.

https://social.msdn.microsoft.com/Forums/vstudio/en-US/6de01933-4855-425c-98cd-8e89487954bc/eliminate-leading-underscore-of-calling-convention-stdcall?forum=vclanguage
Yeah, fun, I found no method to make a working Visual Studio build for both Avisynth versions.
EDIT: perhaps with gcc. Or I make next Avs+ to search for a fully undecorated name when it checks for avisynth_c_plugin_init

[qyot27]

GCC should work fine. That was the original use-case for the C interface anyway, so it wouldn't surprise me if that was the basic assumption about how C plugins would be built (although strangely, IIRC I couldn't get 32-bit AviSynth+-GCC to use the 32-bit AVSInpaint GCC build when I was testing it...or I'm remembering wrong). I don't know if there's an issue here concerning avisynth.def, or not. AssRender seemingly used MSVC despite being a C plugin, and its 32-bit builds interact with MSVC builds of AviSynth with no issue.

It's the main reason I now have to compile 3 different builds of FFmpeg for full AviSynth+ support (one for standard MSVC 32-bit, one for standard MSVC or GCC 64-bit, and one expressly for 32-bit AviSynth+-GCC). stdcall vs. cdecl is just a nightmare on 32-bit.