Avisynth.H files for MinGW builds? [Archive] - Page 2

Jeroi

13th November 2013, 02:45

Ok, I went to the windows and borrowed one 2.6 plugin source and made autotools project out of it and loaded that into Windows Qt creator. Debugged it shown to me that it was necessary to support backwards combatibility by definining windows types to the header, since plugin dev used BYTE and WORD and so on. I also defined windows type ints to the file. Without these additions plugin sources cannot be compiled. How ever in atleast Windows MinGW do support windows c++ headers so this might not be greatest issue of it. Have not taken look about the Linux MinGW libraries.

I have also edited the header a bit as debugger said conflicts with parent and extend classes and some M$ spesific forward declarations. It seems that I have now debugger free and compilable 2.6 header file for mingw but it is very experimental. I need to build dll first and test it with avisynth.

Forensic

14th November 2013, 17:30

Jeroi

14th November 2013, 17:38

While extremely comfortable with AviSynth, creating/understanding header files is currently beyond my skills. I would be extremely appreciative if, should a QT/MinGW32 Avisysnth 2.6 header be successfully created, that someone modify it to support AviSynth 2.5 so I can build DLLs in that legacy environment. I have several scripts that I want to gift to the AviSynth 2.5 community that are only useful under the awesome speed improvements of CPP compiling, and I prefer to work in QT/MinGW32 (their GUI/development tools and available video tutorials appear to dramatically reduce my CPP learning curve). If my request is not possible for technical reasons, please propose an alternate compiler here, in private message or in (http://forum.doom9.org/showthread.php?t=169704)

The obivous answer to you question is to download VCexpress which is free from M$. They will say to you that plugins can only developed in M$ VS because the whole code is M$ spesifig. The main idea in this thread is to get avisynth.h header support for cross platform programs and some developer that may want to develop with other C++ tools avisynth plugins. Also I am including to this project soon the Avxsynth.h so that it can be modified to support windows source plugins to compile them to linux. Mainly replacing the orginal avisynth.h header and introducing avxsynt.h in replace and some modifications to orginal code and build for linux plugin.so.

I just watched avxsynth header, it seams even this project is build with VC++ because it is 2.5 v3 header and no modification to support other compilers. So I think my edited header will be suporting both avxsynth and avisynth both systems. Hah it was funny to watsch some sources ther :D, they have copied all windows defines from windows libs and added them to windows code support so that compiler can handle windows types and definitions. Similar what I am doing with my header to support windows native plugins to be able to build for linux :D.

handaimaoh

14th November 2013, 19:18

Yes, I said I would not respond anymore but I will one more time in the vain hope that you will listen.

The obivous answer to you question is to download VCexpress which is free from M$. They will say to you that plugins can only developed in M$ VS because the whole code is M$ spesifig.

No, the reason you need MSVC++ is because unless you use the C interface you're plugins will not be binary compatible with any Avisynth version in existence. If it was possible to simply modify the header to support building using the C++ interface with MinGW that would actually work with Aviysnth, IT WOULD HAVE ALREADY BEEN DONE. You have not come up with anything either novel or clever. You've simply created something that will never work with any version of Avisynth that any user will be using. This is not some conspiracy to get people to only use the "M$" (a moniker that is highly lame by this point) compiler but simply is due to the realities of C++ compiler ABI incompatibilities in Avisynth's legacy.

Jeroi

14th November 2013, 20:09

Yes, I said I would not respond anymore but I will one more time in the vain hope that you will listen.

No, the reason you need MSVC++ is because unless you use the C interface you're plugins will not be binary compatible with any Avisynth version in existence. If it was possible to simply modify the header to support building using the C++ interface with MinGW that would actually work with Aviysnth, IT WOULD HAVE ALREADY BEEN DONE. You have not come up with anything either novel or clever. You've simply created something that will never work with any version of Avisynth that any user will be using. This is not some conspiracy to get people to only use the "M$" (a moniker that is highly lame by this point) compiler but simply is due to the realities of C++ compiler ABI incompatibilities in Avisynth's legacy.

How come avxsynth can exist then if g++ cannot build abi supported code? I have done code that can give same output to Avisynth that M$ build. It is all about valid code, it does not have to be c++, it can be java, python what ever as long as it outputs correct variables and function definitations. Also there is dtk version of mingw these days that should provide better windows support, so you are wrong. What I can tell is that originally avisynth was coded with M$ code and devs told to people that it is not possible to build with mingw because the code do not work in that environment. That's why it have to redefined with development to support abi with another compiler and this is why C version exists. One guy decided to do another port of the header.

Actually one could use avisynth_c.dll and code c++ there and compile it with g++ to make dll since GCC can do preprosessing the C stuff and use G++ for c++ code.

And I strongly wait avisynth developers to bring them selves header for opensource crossplatform programs to work with if Avisynth will never ever even become native cross platform frame server.

JEEB

14th November 2013, 22:14

How come avxsynth can exist then if g++ cannot build abi supported code?
First of all, the existence of avxsynth has nothing to do with the fact that the C++ specification does not specify an ABI and it is thus completely left to the implementation.

What you really seem to be asking is why something like avxsynth can exist and kind of work (to the level that avxsynth works), including (I have not tried myself but I would guess) C++ API plugins? The reason is simple. On a Linux system you generally have a single ABI, namely the GCC ABI. You don't generally install multiple compilers that have a different ABI on such a system, and most non-GCC vendors try to be at least somewhat compatible with GCC's ABI. For example, Clang does not have 100% ABI compatibility with GCC, but it generally tends to "kind of work" (answer (http://stackoverflow.com/a/11683966/1620828) related to this from circa 2011). I would guess the Linux version of the Intel C++ compiler also supports it in general (related PDF (http://software.intel.com/sites/products/collateral/hpc/compilers/intel_linux_compiler_compatibility_with_gnu_compilers.pdf)).

Now let's go back to Windows. Microsoft set their general C++ ABI with their first C++ compilers, and it has had some changes along the years and versions of their compiler suite. Intel and Borland, among others, support the Microsoft ABI, and thus things built with the other generally work, just like with Linux and the ABI used by GCC. Enter mingw.

Instead of implementing the Microsoft ABI, the people at GCC and mingw decided to just use the same C++ ABI on Windows as they use everywhere else. And thus we have two groups of compilers that use a different ABI, and thus we have problems. If you try to load a mingw-built C++ API DLL from a MSVC-built Avisynth it will not work (related post (http://stackoverflow.com/a/7119896/1620828)). The opposite will not work, either. The C interface was made exactly for this reason, as pretty much by chance the ABI for C is (more or less) set, and thus it is generally OK to mix binaries created by different C compilers.

Do note that the Microsoft and GCC-used C++ ABIs are not the only ones, and that there are other problems surrounding ABIs, including and not limited to exception handling. And this can differ even within GCC binaries thanks to the fact that GCC has multiple ways of doing exception handling, which is configured when the compiler is built.

If you want extra reading regarding calling conventions and name mangling and such ABI-related things, I just seem to have found a PDF that lists quite a few things of various implementations. Available here (http://www.agner.org/optimize/calling_conventions.pdf). Basically these things in general are not fixable by a mere header, you would have to patch a compiler for the other calling convention, as well as handle exceptions so that the other side would understand it as well. And so forth, and so forth.

handaimaoh

14th November 2013, 22:24

How come avxsynth can exist then if g++ cannot build abi supported code?

This is a non-sequitur. The existence of Avxsynth has nothing to do with C++ ABI issues between MSVC++ and MinGW/g++.

I have done code that can give same output to Avisynth that M$ build.

Bull. MinGW does not give the same output that MSVC++ does when compiling C++.

It is all about valid code, it does not have to be c++, it can be java, python what ever as long as it outputs correct variables and function definitations.

Sure if you ignore C++ name mangling differences, exception handling differences, structure alignment differences, etc. These are all limitations acknowledged by the MinGW developers.

Also there is dtk version of mingw these days that should provide better windows support, so you are wrong.

No, I'm not. What you are referring to merely misses the point.

What I can tell is that originally avisynth was coded with M$ code and devs told to people that it is not possible to build with mingw because the code do not work in that environment.

*facepalm* The issue is not with compiling the code. The issue has to do with the ABI of the compiled code. Again, if merely changing the header was the issue, IT WOULD HAVE BEEN DONE SO ALREADY. It is an extreme case of hubris if you really think you're smarter than all the other people who have been working on Avisynth for years.

That's why it have to redefined with development to support abi with another compiler and this is why C version exists. One guy decided to do another port of the header.

MinGW doesn't support the MSVC++ ABI. Redefining a few things in the header does not do what you think it does.

Actually one could use avisynth_c.dll and code c++ there and compile it with g++ to make dll since GCC can do preprosessing the C stuff and use G++ for c++ code.

Sure, if avisynth_c.dll uses the C ABI which is compatible between MinGW and MSVC++. You again, confuse the issues.

And I strongly wait avisynth developers to bring them selves header for opensource crossplatform programs to work with if Avisynth will never ever even become native cross platform frame server.

They will never do so because your headers will break ABI compatibility with every version of Avisynth out there. It would be insanity to do that.

Groucho2004

14th November 2013, 22:26

I have several scripts that I want to gift to the AviSynth 2.5 community that are only useful under the awesome speed improvements of CPP compiling
You'll have to elaborate a bit, that statement makes no sense to me.

Jeroi

14th November 2013, 22:27

And here is again proof that I may be right:

http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

The thing is again that it would nice if Aivisynth finally could adopt GCC supported C++ code in the header.

handaimaoh

14th November 2013, 22:29

http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

That doesn't prove what you think it does.

http://www.mingw.org/wiki/MixingCompilers

Even though GNU g++ can link MSVC C++ libraries now, and can produce MSVC++ compatible libraries/DLLs, this does not mean that they will be able to work at run-time due to the dynamic nature of C++. Some possible reasons for this are:--

The simple name mangling issue which it may be possible to circumvent with an explicit .def file.
Different structure alignment issues which need the correct compiler options (-mms-bitfields, ...).
A fundamental conflict of underlying exception and memory models:--
A new/delete or malloc/free in a MSVC DLL will not co-operate with a Cygwin newlib new/delete or malloc/free. One cannot free space which was allocated in a function using a different new/malloc at all.
An exception raised by an MSVC DLL will not be caught by a Cygwin executable, and vice versa.
The slow GNU SJLJ exception model, (used in GCC-3.x and earlier), is compatible with the MSVC++ model, but the new DWARF2 model, (which will be used by GCC-4.x), will be incompatible.

Jeroi

14th November 2013, 22:31

handaimaoh

14th November 2013, 22:35

The thing is again that it would nice if Aivisynth finally could adopt GCC supported C++ code in the header.

Then go into the Avisynth forum and tell IanB this idea. Considering it will break ABI and all backwards compatibility, I can assure you the likelihood is probably around zero.

handaimaoh

14th November 2013, 22:37

Here (http://forum.doom9.org/showthread.php?t=168764&page=2) is the thread you should use to request what you want, Jeroi.

Moderator note: The posts that this spawned in IanB's alpha thread have been moved back to this thread. Please continue in this thread. IanB is aware of this thread. Thank you.

Jeroi

14th November 2013, 22:46

IanB I have a very honorable, overly talked thingy in my development project, feature question and a really big need for cross platform tools to have native c++ header file and methods to talk with avisynth with these kind of tools http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs. Since cross tools are usually build in MinGW/Linux environments Avisynth could support native C++ language and G++ supporting header file.

I would like to have native header for my MeXgui project to support linking the file with the rest of the code to have windows version that will use avisynth and linux it uses Avxsynth or Avisynth+. Orginaln Megui did not had this issue because it was build from VS but this time project focuse cross platfrom qt application which don't rely on Mincrosoft spesisifc code.

TurboPascal7

14th November 2013, 22:49

Forensic

14th November 2013, 22:55

For legacy compatibility with AviSynth 2.58, all my computers are Windows-7 32-bit. Anxious to just use what is known to work so I can start writing AVIsynth compatible DLLs today, and later create a GUI rich video enhancement program, I have just downloaded:
Qt 5.1.1 for Windows 32-bit (VS 2012, 511 MB) {http://qt-project.org/downloads}
Microsoft Visual Studio Express 2012 for Windows Desktop {http://www.microsoft.com/en-us/download/confirmation.aspx?id=34673}
If I am understanding this correctly, these tools should play nicely with the avisynth.h (2.5 v3) {http://avisynth.nl/images/Avisynth.h-2.5.8.avs}. If so, bye bye minGW32 and hello plug-in creation. Does the above make sense? Thank you in advance.

handaimaoh

14th November 2013, 22:58

Groucho2004

14th November 2013, 23:02

Could you please provide a binary of a more or less complex avisynth plugin, built with g++, that would work with existing avisynth builds on windows?

Of course it should use the C++ interface as you propose.
You're so cruel. ;)

handaimaoh

14th November 2013, 23:33

BTW Jeroi, how exactly did you compile a plugin with your MinGW headers when you have typos in the code? In your "avisynth26.h" you have a typo on the ApplyMessage method of IScriptEnvironment where you have "_stdcall" instead of "__stdcall". Even excluding that, I've yet to find a single version of your headers that even compile with my MinGW that uses GCC 4.8.1.

Guest

14th November 2013, 23:35

...
If you want extra reading regarding calling conventions and name mangling and such ABI-related things, I just seem to have found a PDF that lists quite a few things of various implementations. Available here (http://www.agner.org/optimize/calling_conventions.pdf). Basically these things in general are not fixable by a mere header, you would have to patch a compiler for the other calling convention, as well as handle exceptions so that the other side would understand it as well. And so forth, and so forth. Thanks for that valuable post with excellent links, JEEB!
:thanks:

handaimaoh

14th November 2013, 23:36

Jeroi
This is a very interesting idea indeed. Could you please provide a binary of a more or less complex avisynth plugin, built with g++, that would work with existing avisynth builds on windows?

Of course it should use the C++ interface as you propose.

He can't. For one thing his MinGW headers don't seem to be able to compile with MinGW in all the tests I've tried. Furthermore, even if many of the errors I'm seeing is merely an issue on my side his header for Avisynth 2.6 has a typo of "_stdcall" instead of "__stdcall" on the ApplyMessage method of IScriptEnvironment which would prevent compilation success.

handaimaoh

14th November 2013, 23:37

Thanks for that valuable post with excellent links, JEEB!
:thanks:

Yes out of everything in this thread it was quite an awesome PDF. Agner Fog's docs are awesome!

Guest

15th November 2013, 00:22

He can't. I'm pretty sure that's why TurboPascal7 posed the question. ;)

Jeroi

15th November 2013, 11:04

IanB I have a very honorable, overly talked thingy in my development project, feature question and a really big need for cross platform tools to have native c++ header file and methods to talk with avisynth with these kind of tools http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs. Since cross tools are usually build in MinGW/Linux environments Avisynth could support native C++ language and G++ supporting header file.

To add to my question would it be possible to define all the __sdtcalls with __declspec(dllexport/import) to allow more better MINGW support? __stdcalls seem to have problems with namemangling but __declspec seem to be standart c++ that mingw should handle with similar to MSVC.

TurboPascal7

15th November 2013, 11:07

Wow, the guy sees only what he wants to see?
Don't just go and ignore my question, Jeroi.

Jeroi

15th November 2013, 15:55

Wow, the guy sees only what he wants to see?
Don't just go and ignore my question, Jeroi.

I can build but need to change those sdtcalls to declaspec and since avisynth uses stdcalls the dll might not work because stdcall is in MSVC def file _function$plaah where in mingw it is function$plaah.

How to go arround this problem is produce the windows dll with a bit harder method with DEF file to make DLL support dll's that use __declspec(export).

See: http://wyw.dcweb.cn/stdcall.htm

If dll plugin header uses stdcall it pretty much kills mingw support.

The header could be written like this:

#ifdef PLUGIN
#define EXPORT __declspec(export)
#end
#define EXPORT __declspec(inport)
#endif

Then replacing all calls in the avisynth header with:

EXPORT int __cdecl Add(int a, int b)

Since __cdecl is handled similar with MSVS and MINGW this would provide intial support for plugins builded from mingw.

The downsode of this change is plugin sources need to recombile with new header while but whats is more greater is to add support mingw builds.

All this would change the current issue of plugins buildable only at Visual Studio and since plugins cuild be build in mingw natively wihtout def files it would provide Cross Platfrom softwares avisynth support natively in Windows.

handaimaoh

15th November 2013, 16:00

Well, yes, that is part of what I was trying to beat into your head. The only way for what you want to work is to use avisynth_c.h. Any other option breaks ABI and thus all backwards compatibility. And at that point, what's the point of using Avisynth if all your plugins are no longer compatible? You might as well just move to something like Vapoursynth.

handaimaoh

15th November 2013, 16:29

This would provide intial support for plugins and then in windows avisynth.dll should be build with DEF file so that decorations are off from Avisynth.dll.

Now only downside for this change is that all plugins need to be build against this new header file to support it.

All this would change the current issue of plugins buildable only at Visual Studio and since plugins cuild be build in mingw natively wihtout def files it would provide Cross Platfrom softwares avisynth support natively in Windows.

You do realize that's a huge downside right? And why would anyone use your headers and rebuild their plugins such that they would be incompatible with every version of Avisynth in existence?

Edited to add:
BTW Jeroi, you do realize that both Avisynth and most Avisynth plugins contain inline x86 asm that is incompatible with g++, right? One cannot simply recompile either Avisynth or the vast majority of plugins without major rewrites and ports even with your modified header. I'm not even sure if at this point Avisynth+ can be compiled with MinGW (I could be wrong though). No one is going to put in the effort to do all that work merely to be able to use the Avisynth C++ interface in MinGW.

Jeroi

15th November 2013, 16:42

Edited to add:
BTW Jeroi, you do realize that both Avisynth and most Avisynth plugins contain inline x86 asm that is incompatible with g++, right? One cannot simply recompile either Avisynth or the vast majority of plugins without major rewrites and ports even with your modified header. I'm not even sure if at this point Avisynth+ can be compiled with MinGW (I could be wrong though). No one is going to put in the effort to do all that work merely to be able to use the Avisynth C++ interface in MinGW.

You can still build everything in MSVS. But you can develop new plugins in mingw and use the header with mingw build apps.

The downside is that current plugins need to be build again with new header in MSVS to support new header version.

I'm not even sure if at this point Avisynth+ can be compiled with MinGW (I could be wrong though). No one is going to put in the effort to do all that work merely to be able to use the Avisynth C++ interface in MinGW.

No it cannot, one of the main issues is the avisynth header and since Avisynth+ has not announced linux support yet. In achieving this task the header file _MUST_ be changed. It is the most important issue with current Avisynth.

handaimaoh

15th November 2013, 16:47

The header could be written like this:

#ifdef PLUGIN
#define EXPORT __declspec(export)
#end
#define EXPORT __declspec(inport)
#endif

Then replacing all calls in the avisynth header with:

EXPORT int __cdecl Add(int a, int b)

Since __cdecl is handled similar with MSVS and MINGW this would provide intial support for plugins builded from mingw.

So then why not merely use the avisynth_c.h which uses __cdecl so that you can use MinGW to create plugins? It seems now you are simply creating a buggier version of the already existing Avisynth C interface.

You can see it here (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/avisynth_c.h?revision=1.8&view=markup).

You can still build everything in MSVS. But you can develop new plugins in mingw and use the header with mingw build apps.

The downside is that current plugins need to be build again with new header in MSVS to support new header version.

And I am aware that this breaks 2.5 support and so on but what is greater is support Cross compilable programs and avisynth plugins.

Since for most thing to other programs is just to use new header file for next build of the program, so every programs could adopt new version of header in sooner or later. In mean time they use 2.5 combatible plugins.

Or one can simply just use the already existing Avisynth C interface that won't break backwards compatibility with 2.5 compatible plugins? Your interface offers nothing of benefit over the existing C interface and on the other hand requires recompiling plugins and breaking compatibility. You've created essentially nothing of value over what already exists.

No it cannot, one of the main issues is the avisynth header and since Avisynth+ has not announced linux support yet. In achieving this task the header file _MUST_ be changed. It is the most important issue with current Avisynth.

Adding Linux support would not mean breaking existing ABI with all current Windows plugins as your header does foolishly.

Jeroi

15th November 2013, 16:56

Or one can simply just use the already existing Avisynth C interface that won't break backwards compatibility with 2.5 compatible plugins? Your interface offers nothing of benefit over the existing C interface and on the other hand requires recompiling plugins and breaking compatibility. You've created essentially nothing of value over what already exists.

Adding Linux support would not mean breaking existing ABI with all current Windows plugins as your header does foolishly.

Yes will use that for my current project, but it would be nice to see the header to switch using more standart c++ language to provide support mingw building.

handaimaoh

15th November 2013, 16:57

Yes will use that for my current project, but it would be nice to see the header to switch using more standart c++ language to provide support mingw building.

It does support MinGW building. That was the whole reason the C interface was created. This is what I told you 2 days ago.

Which as I said, is only the start of your problems. You can not get around the ABI issue no matter what you do. Do you really think if merely changing some things in the header and recompiling with MinGW would have worked no one would have done so already? As I said before, the only way to get what you want is to either use avisynth_c.h or create your own C header. But it will have to be ABI compatible as well which you seem to have no notion of what that means or why it is important.

You then brushed me off. And now you've simply been talking about poorly re-implementing it.

Guest

15th November 2013, 22:03

Posts have been moved from IanB's thread to this one.

@Jeroi

Please confine your discussion to this thread. Thank you.

Jeroi

19th November 2013, 07:15

It does support MinGW building. That was the whole reason the C interface was created. This is what I told you 2 days ago.

You then brushed me off. And now you've simply been talking about poorly re-implementing it.

Yes you have been right with the C header all a long, but originally the thread is for development of C++ header which at current state is way too M$ code to support mingw build, and the fact it uses stdcall instead of cdecl is one of the reason why it does not work with mingw. If you call that brushing you off, then you are right. I my point of view, you are in past, I look for future.

And yes, atm they are broken and in development, you can download the code see the bugs and re edit them. This is opensource.

Guest

19th November 2013, 13:46

Jeroi

19th November 2013, 16:05

So you are saying just a few bugs stop the header file from giving us cross-platform operability using the C++ interface? If you really believe that, can you please explain how the header file (when 'fixed') can solve the problems of ABI incompatibility?

Well there will not be ABI incompatibility when cdcl is used like C plugin does it. This is because gcc and g++ can handle cdcl and combile dll that has "fucntion@m" like MSVC has "function@m" so both compilers can produce equal dll. If u use stdcall You will produce with mingw "function@m" and MSVC will output functions as "_fucntion@m". This breaks mingw DLL functions work because Avisynth.dll waits "_function@m" input. For similar reason current avicynth C plugin autoloading does not work and atm Avisynth+ can handle C plugin input just fine, that is compiled with mingw. The main problem is that if we change avisynth.H into avisynth.dll it then need to provide backwards support via stdcalls. This means that we would need to produce 2 versions, one for mingw build and one avisynth.h that support both function styles input at Windows. Lets say that WIN only version should be reanmed to avisynth_win.H and crossplatfrom supported version without stdcalls should use avisynth.h This provides mingw to be able to build functions with cdcl and be able to run the DLL's in Avisynth windows.

The main reason for all this is to enable native cross platfrom build support for avisynth. How ever it have said that C file does exist already and you can use it to provide avisynth support. My main consider is that does avisynth_c.h be autoload version in Windows? I mean when program X, wants to import avs file in Windows, and the program has avisynth_c.h included in bin, is it able to load those functions calls automatically with avisynth with it?

Let's say that program wants to import Audio and video data, it writes functions that use cdcl to to fetch from avisynth dll the video and audio, can avisynth then respond automatically to cdcl calls?

Guest

19th November 2013, 17:38

I will interpret what you say as acknowledging that the problem cannot be solved with a header file and that your project cannot meet its goals. It's important to get this in the open so other people do not needlessly waste their time trying to achieve something that is known to be impossible.

handaimaoh

19th November 2013, 18:01

Yes you have been right with the C header all a long, but originally the thread is for development of C++ header which at current state is way too M$ code to support mingw build, and the fact it uses stdcall instead of cdecl is one of the reason why it does not work with mingw. If you call that brushing you off, then you are right. I my point of view, you are in past, I look for future.

And yes, atm they are broken and in development, you can download the code see the bugs and re edit them. This is opensource.

I know I've been right. It's good to see you finally realize that. Also, I'm not looking into the past at all. If you want to be able to use C++ interface classes like in the regular Avisynth.h simply create such a C++ wrapper that calls into the C header functions behind the scenes. The major benefit is that doesn't require ABI breakage thus making such plugins incompatible with every Avisynth install in existence.

Well there will not be ABI incompatibility when cdcl is used like C plugin does it.

Changing the calling convention breaks ABI... As to the rest of your post, I know very well what the differences between cdecl and stdcall are so I don't need your lesson. And it is much more involved than what you mention. cdecl and stdcall are also different in whether it's the callee or caller who cleans up the arguments from the stack. You will probably run into issues with inline asm functions due to this (although your bigger issue is simply the incompatibility between MSVC and g++ inline asm).

Jeroi

22nd November 2013, 22:58

You will probably run into issues with inline asm functions due to this (although your bigger issue is simply the incompatibility between MSVC and g++ inline asm).

No that is not a great issue. You can still build plugins with MSVC and use inline assembly. But you will lose unix support if your plugin uses inline assembly. Use native asm assembly would generate unix support for the plugin. This would be in future must anyway to support unix usage of the plugin.

But the main issue is current header limitation which is too win spesific with those stdcalls. If these are changed to cdecl it means only recombile the plugin which has inline assembly. This is not a big issue for plugin devs. The inline to asm is more bigger one for them.

The most backward support would provide 2 headers, one that stays native win but has no future support and the new cdecl header that implements c++ native functions and provides native c++ build support for every plugin/guiprogram that has full support.

In future when programs are moving to use cdecl calls the stdcall header could be removed as the time goes by.

Development sometimes need drastic movements and towards cross platfrom support to stay touch with the time.

handaimaoh

22nd November 2013, 23:13

But the main issue is current header limitation which is too win spesific with those stdcalls. If these are changed to cdecl it means only recombile the plugin which has inline assembly. This is not a big issue for plugin devs. The inline to asm is more bigger one for them.

Wrong. You can not change the C++ header from stdcall to cdecl and expect the plugins to work. Best case the plugins will crash and at worse you will have all sorts of bugs at runtime. There is more to the difference between cdecl and stdcall than you seem to realize.

The most backward support would provide 2 headers, one that stays native win but has no future support and the new cdecl header that implements c++ native functions and provides native c++ build support for every plugin/guiprogram that has full support.

Except that simply using cdecl doesn't solve the C++ ABI issue between MSVC and MinGW/g++. Things such as exception handling, data alignment, etc are likely to cause runtime issues. You're missing the forest for the trees.

In future when programs are moving to use cdecl calls the stdcall header could be removed as the time goes by.

Development sometimes need drastic movements and towards cross platfrom support to stay touch with the time.

Except that going cross platform in no way requires obliterating ABI compatibility for Windows. Vapoursynth is cross-platform and is ABI compatible with Avisynth plugins on Windows.

Jeroi

22nd November 2013, 23:21

Wrong. You can not change the C++ header from stdcall to cdecl and expect the plugins to work. Best case the plugins will crash and at worse you will have all sorts of bugs at runtime. There is more to the differences between cdecl and stdcall than you seem to realize.

Except that simply using cdecl doesn't solve the C++ ABI issue between MSVC and MinGW/g++. Things such as exception handling, data alignment, etc are likely to cause runtime issues. You're missing the forest for the trees.

Except that going cross platform in no way requires obliterating ABI compatibility for Windows. Vapoursynth is cross-platform and is ABI compatible with Avisynth plugins on Windows.

The runtime issues are for avisynth devs, we here talk about supporting C++ header for programs to call avisynth when video is needed in the program. When avisynth supports unix, the devs need to change all that so it supports both systems. Until avisynth becomes unix stable I think Avisynth+ has a better chance but it has the header thingy also. It uses exact same header.

Well in unix these functions are ignored in the build prosess and used are only normal functions that are public at unix but this means building with g++ at linux and building with msvc at windows. How ever does vstudio handle good autotools and qt projects?

handaimaoh

22nd November 2013, 23:27

The runtime issues are for avisynth devs, we here talk about supporting C++ header for programs to call avisynth when video is needed in the program. When avisynth supports unix, the devs need to change all that so it supports both systems. Until avisynth becomes unix stable I think Avisynth+ has a better chance but it has the header thingy also. It uses exact same header.

Well in unix these functions are ignored in the build prosess and used are only normal functions that are public at unix but this means building with g++ at linux and building with msvc at windows. How ever does vstudio handle good autotools and qt projects?

They don't need to change anything for Windows. You simply use ifdefs and nothing is broken.

TurboPascal7

22nd November 2013, 23:43

Until avisynth becomes unix stable I think Avisynth+ has a better chance but it has the header thingy also. It uses exact same header.

Avisynth+ will get a C API when coming to Linux of course, most likely with a thin C++ wrapper provided for convenience.

Now I have a question: why do you even bother with this header? Vanilla avisynth will never work on linux and you won't port it. What do you want to achieve?

Guest

23rd November 2013, 02:22

He wants to bring all of Doom9's developers out of the past and into the future:

Development sometimes need drastic movements and towards cross platform support to stay touch with the time.

handaimaoh

23rd November 2013, 02:51

Avisynth+ will get a C API when coming to Linux of course, most likely with a thin C++ wrapper provided for convenience.

Now I have a question: why do you even bother with this header? Vanilla avisynth will never work on linux and you won't port it. What do you want to achieve?

He was apparently unaware of the C interface that already existed for quite some time now and thus was trying to poorly recreate it by creating a Frankenstein header file from the C++ interface. Why he continues to persist down this path after knowing of the C interface's existence, though, is definitely a mystery. Especially when he doesn't understand ABIs, calling conventions, etc. and doesn't understand why what he's doing is not as simple as he's making it out to be. But then again with choice quotes like:

The runtime issues are for avisynth devs

I couldn't help but laugh my butt off.

Jeroi

23rd November 2013, 09:19

He was apparently unaware of the C interface that already existed for quite some time now and thus was trying to poorly recreate it by creating a Frankenstein header file from the C++ interface. Why he continues to persist down this path after knowing of the C interface's existence, though, is definitely a mystery. Especially when he doesn't understand ABIs, calling conventions, etc. and doesn't understand why what he's doing is not as simple as he's making it out to be. But then again with choice quotes like:

I couldn't help but laugh my butt off.

Well I am not interested to develop avisynth, there are others for that. Also I am not naming you with any names. But glad that I can entertain you. Instead of calling me as poor please do some work for these projects and we can have mutual respect for each other. I also took the risk to talk people like you, who comment work that is not complete, in development, asking people to join. I am fully aware that people like you exists. And for the record I do have Java and C background so jumping to these projects are a learning prosess but satisfactory to do.

TurboPascal7

23rd November 2013, 14:07

Well I am not interested to develop avisynth, there are others for that.
These "others" and a few more people already told you - this will never happen. Give up. No one will (help you) modify avisynth C++ API to get it compatible with mingw because it's freaking impossible. Use the existing C API if you want to compile anything with mingw right now.

C++ API compatible with different compilers will most likely be added to Avisynth+ in the future as a wrapper around a C API.

Before that, if you're targeting GNU/Linux, VapourSynth is your best bet. Stop wasting your time.

Guest

23rd November 2013, 14:57

No one will (help you) modify avisynth C++ API to get it compatible with mingw because it's freaking impossible. Use the existing C API if you want to compile anything with mingw right now.

C++ API compatible with different compilers will most likely be added to Avisynth+ in the future as a wrapper around a C API. That sounds inconsistent to me. Why couldn't Jeroi also make a C++ wrapper around the C interface? It's possible if you do it but not Jeroi? I don't get it.

The impossibility here is the idea of cross platform runnability of the executables.

I guess we're back to asking Jeroi exactly what he is trying to accomplish. Just rambling about "cross platform is needed for modern times" is too nebulous to convey any real meaning.